Re: HTTP client q

[Andrew Moore <Andrew.Moore@xxxxxxxxxxxx>]

Hmm actually that is probably precisely wrong.

1.0 servers are the very ones that are fragile to unrecognised control words.

in particular they are all those ratty web-accessible cameras and that sort of 
crap - worst offenders a crappy series of home gateway routers that would get 
way confused and jam.

I'd be inclined to be highly conservative for ancient kit

Also 1.0 is still shockingly commonplace among load balancers that go 
insane/under-attach; stupid but true

On 14 Nov 2012, at 18:05, Anil Madhavapeddy wrote:

> 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
>> 
>> 
> 
>