Re: pconns and WHEN_SQUID_IS_NOT_HTTP1_1

On Thu, 15 Sep 2005, Alex Rousskov wrote:

> I am not sure I agree. Persistent connection is an optional optimization
> without any guarantees (regardless of the protocol version). From
> protocol point of view, it should be safe to send keep-alive in every
> message with known length. What am I missing? Why do we need the
> requester to understand the keep-alive token?

Because not all clients cares about content-length for message delimiting
when they know the connection is not persistent, and as I said an HTTP/1.1
client does not need to know that "(Proxy-)Connection: keep-alive" makes
the connection persistent.

> Are we concerned about who is going to close the connection first?

Yes, or more precisely that the client should not need to wait for log for
the connection close before considering the transfer completed.

>> The HTTP/1.0 keep-alive was never accepted into any standard
>
> [ Side note: How about RFC 2068, Section 19.7.1? RFC 2616 cites it. ]

Only the client->origin variant, not the client->proxy variant however..

> This is a difficult case since it is not clear whether the response
> version or the lack of the keep-alive token take precedence. We can
> assume "Connection: close", but what would be the harm in assuming a
> persistent connection?

Indeed, but I prefer taking the safest approach possible.

It is relatively bad to send a request on a non-persistent connection.
This will surely result in a failed transmission, network overhead and
additional latency as the request needs to be retried.

> [ An HTTP/1.1 server that does not send Connection: header to HTTP/1.0
> client (that did send it!) should be fixed, IMO ]

Agreed.

> I understand now, but I am not sure why assuming persistent connection
> was a bug. Do you recall what was happening when connections were
> assumed to be persistent?

Mostly failed transmissions as the connection then got closed while we
were sending the next requests I think, but I also recall a some memory of
a stall situation in proxy hierarchies where the request hung until
timeout. (details of this memory very dim today however).

> Now, it seems like we will need two things:
>
> bool HttpMsg::wantsPconn(void) const;
> and
> bool connIsPeristent(const HttpRequest &, const HttpReply &);
>
> with all the above questions applying to the second function, not the
> first.

Looks good to me. Just need to remember to use the request/response
relevant to the same connection (not client-side request on server-side
connection etc)..

Regards
Henrik
Received on Fri Sep 16 2005 - 04:47:35 MDT