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
