Re: pconns and WHEN_SQUID_IS_NOT_HTTP1_1

On Wed, 7 Sep 2005, Alex Rousskov wrote:

> Should it be named WHEN_SQUID_IS_HTTP1_1 instead?

Probably. It is in the 2.5 version..

> Can the intended semantics of httpMsgIsPersistent() be summarized as
>
> "The HTTP agent sending the supplied message
> wants to keep the connection persistent (AND
> we trust that agent can handle pconns)."
>
> That is,
>
> "Keep the connection with the agent persistent
> if possible"

Yes.

> Or is it something else? I am afraid it is something more convoluted because
> I see client_side.cc forcing the HTTP version to 1.0 before calling that
> method(*).

If I am not mistaken this hardcoding to 1.0 was the earlier partial fix to
the same problem. Can be removed now. Only need to make sure that removing
this does not cause us to forward the requests as HTTP/1.1.. (I think this
is already made sure elsewhere so it should be safe..).

> The corresponding(?) bugzilla comment says
>
> "... uncovered another HTTP compliance bug in Squid where HTTP/1.1
> messages was considered (partly) as implicitly keep-alive even if Squid is
> still HTTP/1.0."
>
> What is wrong with considering HTTP/1.1 messages keep-alive by default? Are
> we trying to catch cases where a (broken?) HTTP/1.1 agent expects Squid to
> default to non-persistent connections because Squid is HTTP/1.0?

HTTP/1.0 keep-alive can not be enabled unless the request explicitly
says this is understood by the requestor. HTTP/1.1 alone does not imply
that the requestor implements HTTP/1.1 keep-alive as the signaling methods
of HTTP/1.1 and HTTP/1.0 keep-alive is quite different. The HTTP/1.0
keep-alive was never accepted into any standard, and can not be assumed to
be understood unless signalled.

Additionally a HTTP/1.1 response to a HTTP/1.0 request does not not
automatically imply keep-alive even if the response is a HTTP/1.1
response. This is what the quote from the bug report is about.

> Are we always sending explicit Connection: close/keep-alive headers?

Yes.

> Would that take care of any ambiguities when talking to HTTP clients,
> regardless of the client HTTP version? Same for servers?

The problem the mentioned patch addresses is Squid<->Server communication.

The other client side fragment (forcing http version to 1.0) was an
earlier fix to the same problem on Client<->Squid traffic.

> (*) Although the version parameter of httpMsgIsPersistent() is currently
> unused.

As it should be while we are HTTP/1.0 only.

Regards
Henrik
Received on Sat Sep 10 2005 - 15:54:41 MDT