Re: HTTP client q

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

Unfortunately, clients have no idea what the server version is, so we pretty 
much have to make an HTTP/1.1 query by default, and only fall back on error...

-anil

On 14 Nov 2012, at 19:03, Andrew Moore <Andrew.Moore@xxxxxxxxxxxx> wrote:

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