Re: bug #94 news

On Thu, 3 Oct 2002, Adrian Chadd wrote:

> 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?

httpState->fd is the server connection, not the client connection... so
naturally the fd's should be different...

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

What client?

httpState has no opinion on what is the client filedescriptor, and nothing
in http.c should really need to know. The client address can be found in
the request, so why does it loop over to the client side of things?

But one more thing can be said in favor of http.c: This request should
have been aborted when the client connection was closed. It obviously have
not completed the reply headers (we have not yet sent the request headers)
so Why was the request not aborted (CheckQuickAbort..)? Or maybe it was..
see the StoreEntryflags..

Regards
Henrik
Received on Fri Oct 04 2002 - 03:09:07 MDT