Re: HTTP client q

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Hm, so given our client by default is 1.1, this change is ok. But of course,
if we receive back an HTTP/1.0 downgrade from the server then all bets are
off. I'm inclined to add the header for now by default, and it'll be ignored
for 1.0 servers (which are presumably reasonably rare nowadays, although maybe
not for embedded devices).

What a barking mad protocol:
http://wiki.basho.com/images/http-headers-status-v3.png

Of course, every single step in that flowchart can be justified.
It's just the big picture that's insane :)

-anil

On 14 Nov 2012, at 18:00, Andrew Moore <Andrew.Moore@xxxxxxxxxxxx> wrote:

> My read is
> 
> 1.0 not valid
> 
> 1.1 must have for non persistent (aka no Connection: Keep-Alive)
> 
> I don't have a mapping of that to "more advanced API" you speak of.
> 
> a.
> 
> On 14 Nov 2012, at 17:33, Anil Madhavapeddy wrote:
> 
>> To the HTTP heads out there, is it ok for a single HTTP request (no 
>> pipelining) to always include "Connection: close" in the headers?
>> 
>> In Cohttp, we currently don't do this, and it appears that every single 
>> client has to include the header, or risk the other side not closing the 
>> connection cleanly.
>> 
>> I'm modifying Cohttp to always send the Connection header when a single 
>> get/put/post/head request is issued, but *not* when the more advanced 
>> pipeline API calls are used.  Does this sound sane?
>> 
>> -anil
> 
> 
> Relevant extract RFC2616 *and there might be something more recent, I can't 
> find ight now, it is not clear that the follower RFCs explicitly obsolete 
> this.
> 
> 
> 
> HTTP/1.1 defines the "close" connection option for the sender to signal that 
> the connection will be closed after completion of the response. For example,
> 
>       Connection: close
> 
> in either the request or the response header fields indicates that the 
> connection SHOULD NOT be considered `persistent' (section 8.1) after the 
> current request/response is complete.
> 
> HTTP/1.1 applications that do not support persistent connections MUST include 
> the "close" connection option in every message.
> 
> A system receiving an HTTP/1.0 (or lower-version) message that includes a 
> Connection header MUST, for each connection-token in this field, remove and 
> ignore any header field(s) from the message with the same name as the 
> connection-token. This protects against mistaken forwarding of such header 
> fields by pre-HTTP/1.1 proxies. See section 19.6.2.
> 
> 14.11
> 
>