On Sat, Jun 22, 2013 at 10:07 AM, Lieven Govaerts <svnlgo_at_mobsol.be> wrote:
> On Sat, Jun 22, 2013 at 9:08 AM, Philip Martin
> <philip.martin_at_wandisco.com> wrote:
>> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>>
>>> Problem with this approach that some servers may support HTTP/1.1
>>> partially. I.e. declare them as HTTP/1.1 but do not support chunked
>>> Transfer-Encoding.
>>>
>>> I wanted to avoid downgrade to HTTP/1.0 on later requests because it
>>> could introduce requests ordering issue. For example:
>>> C: HTTP/1.0 OPTIONS /
>>> S: HTTP/1.1 Response
>>>
>>> C: HTTP/1.1 PROPFIND
>>> C: HTTP/1.1 GET
>>> S: HTTP/1.1 411 Length required
>>> S: HTTP/1.0 200 OK
>>>
>>> Then client send PROPFIND request again:
>>> C: HTTP/1.0 PROPFIND
>>> S: HTTP/1.1 200 OK
>>>
>>> But requests was completed and different order than our update editor
>>> expected and most likely crash :(
>>
>> Suppose serf were to keep track of the number of outstanding requests
>> (it may already do that I haven't checked). Then if the number of
>> outstanding requests is zero when the 411 is received the downgrade to
>> HTTP/1.0 will be OK. Lots of client operations start with multiple
>> requests in serial before switching to pipelined requests, so in all
>> those cases the downgrade will work.
>
> We need a solution for all cases, most is not enough.
>
> Given the requirement of the first request's mandatory http/1.0 and
> strict ordering of req/resp in pipeline mode, I don't see how we can
> identify both http/1.1 compliance and chunked encoding support with
> only one non-pipelined request.
>
> Why not play it safe then and send one extra request on the first
> connection in the context?
>
> The first request is a HTTP/1.0 request to detect if the connection
> can be upgraded to HTTP/1.1.
> The second request (the PROPFIND) is sent using chunked encoding to
> detect if that's supported.
> If 411 is received fallback to HTTP/1.0 mode, otherwise continue with
> HTTP/1.1 + chunked encoding.
Maybe I'm missing something, but why would you downgrade to HTTP/1.0
only because of the 411 (Content Length Required)? Can't you just
continue using HTTP/1.1, but use CL instead of chunked requests? Or is
falling back to HTTP/1.0 just the quickest solution within the current
implementation?
IIUC HTTP/1.1 has other advantages besides chunked encoding, and can
be used perfectly well without it. So it seems you can fall back to
HTTP/1.1 + ContentLength here, no?
> This will add one round-trip of overhead for every serf session, and
> it impacts all users, even those that are not behind such (outdated)
> proxies.
>
> I'd support making this dependent on a 'http1.0_server" option in the
> servers runtime configuration. With this option it only impacts those
> users that are working behind outdated proxies. We can include the
> necessary instructions for users in the error description of the
> by-default-unexpected 411 response.
>
> This should also be a clear trigger for hosting companies to upgrade
> their proxy infra.
I'd favor always auto-detecting, even at the cost of the extra
round-trip. Or perhaps make the default auto-detection, and have a
flag to shortcut the auto-detection if you know what you're doing.
--
Johan
Received on 2013-06-22 10:24:57 CEST