On Sat, 2005-09-10 at 23:54 +0200, Henrik Nordstrom wrote:
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.
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?
Are we concerned about who is going to close the connection first? Some
other performance optimization like that? Or is it related to the known
message length issues?
HTTP/1.1 alone does not imply
that the requestor implements HTTP/1.0 keep-alive
Agreed, but the above reasoning about pconns being an optimization
without guarantees should still apply. If the agent does not recognize
the keep-alive token, it will just treat the connection as
non-persistent, right? An agent may do that for many other reasons as
well, even if it does recognize the keep-alive token!
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. ]
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 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?
[ An HTTP/1.1 server that does not send Connection: header to HTTP/1.0
client (that did send it!) should be fixed, IMO ]
This is what the quote from the bug report is about.
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?
The primary reason for these questions is the desire to make
httpMsgIsPersistent() an HttpMsg method without breaking too many
things, and with future HTTP/1.1 support in mind. At the first glance,
we do not need any information external to the message (and the old
interface kind of confirms that). Either message implies persistency or
it does not. But then I noticed old code that supplies http version that
does not come from the same message as the supplied http headers and
paused...
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.
Thank you,
Alex.
