On Fri, 2001-11-16 at 13:27, Graham Leggett wrote:
> Ian Holsman wrote:
>
> > I've had a better look into this problem and I think I figured what is
> > causing it.
> >
> > We store state info in the connection record which holds the
> connection
> > handle and other stuff.
>
> This is correct - it's done so keepalive can work.
>
> > The problem seems to occur when we request a page which has virtual
> > includes which request another page on the same server.
> >
> > what happens is the 2nd request grabs the connection (which is still
> > midway through the 1st request) and issues another request on the same
> > connection.
> >
> > now this may be fine for things which understand pipelining. but
> > I think it is screwing up 1.0 servers.
>
> Even with pipelining it won't work - we're in the middle of a request
> trying to make a new request, not at the end of the request :(
>
> > the only way I can think of getting around this is to store state at
> the
> > request level instead of the connection level.
>
> This will break keepalives.
>
> Rather fix it so that when proxy tries to write state to the connection
> record, it checks first whether a state already exists. If a state does
> exist then we have triggered our bug - get proxy to *not* write the
> state and just serve a "Connection: close" on the subrequest.
>
> The consequences of this are that keepalives cannot be supported for
> subrequests within requests, however considering that practically a
> page-within-a-page cannot logically follow the original page request
> this should be fine.
thats what I thought...
I fixed it up in our internal patched version (header_hook+HTTP/1.0
only)
I'll get the CVS one fixed up over the weekend)
>
> Regards,
> Graham
> --
> -----------------------------------------
> [EMAIL PROTECTED] "There's a moon
> over Bourbon Street
> tonight..."
--
Ian Holsman [EMAIL PROTECTED]
Performance Measurement & Analysis
CNET Networks - (415) 344-2608
