On Sat, Jun 22, 2013 at 10:24 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> 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?
There are only 2 differences between 'http 1.0 mode' and 'http 1.1
mode' in ra_serf. First is using Content-Length instead of chunked
encoding. The second is that the Connection:keep-alive header is set
on all responses.
I actually expected a third difference, pipelining should be disabled
in http 1.0 mode via set_max_outstanding_requests call, but I don't
see that in the code. gstein?
> 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?
Yes, that's indeed possible. It does add yet another variant of
communication though. IMO we already have more options than we can
support, we should cut down in the multitude of ways we support legacy
systems.
>> 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.
That'd be the 'http1.0_server' flag, or the cached flag I've mentioned
in my other mail.
> --
> Johan
Lieven
Received on 2013-06-22 11:13:28 CEST