Re: bug #94 news

On Fri, Oct 04, 2002, Henrik Nordström wrote:

> which is pretty fine.. and to deal with this all we have to do is to
> ensure that we do not rely on the client filedescriptor in http.c. The
> only use of the client filedescriptor in http.c is for the Forwarded-For
> http header in httpBuildRequestHeader...

Right.

> Hmm.. the closed case should be dealt with properly. When the client
> descriptor is closed the mem_obj->fd SHOULD be set to -1. If it is http.c
> will be happy.

Again, right. Hm. If the client side of the request is over though,
hm. Where's the comm_write_mbuf going? :)

Ah. Its going out httpState->fd, _which_ I note ..

(gdb) print httpState->fd
$24 = 12
(gdb) print fd_table[httpState->fd].flags
$25 = {
  open = 1,
  close_request = 0,
  write_daemon = 0,
  closing = 0,
  socket_eof = 0,
  nolinger = 0,
  nonblocking = 1,
  ipc = 0,
  called_connect = 1,
  nodelay = 1,
  close_on_exec = 1,
  read_pending = 0
}
(gdb)

Why would the fd's be different?

> > So, it _sounds_ like a possible problem with BOTH persistent
> > client/server connections, perhaps?
>
> Perhaps, but looking at the code again I think the persistent connections
> question is irrelevant.

Hm. It might have something to do with a race condition brought on by
persistent connections, but I can't easily tell.

> More relevant is probably the question on which mem_obj this actually is,
> and how the client filedescriptor knows it is referenced by this mem_obj..
> A quick grep on the sorce reveals that it most likely does not know at
> all... mem_obj->fd is only assigned at one place (in forward.c) and only
> used by the suspected code in http.c, and there only to be able to insert
> the client address in the forwarded headers..

Yup, I definitely agree. Why can't we just use httpState->fd?
Aren't we forwarding for _THAT_ client? :)

Adrian
Received on Thu Oct 03 2002 - 23:30:34 MDT