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
