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.
>
> 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.
Even better if we could cache this info somewhere automatically. So
that the first time svn connects to a server ever it will use this
'slow' procedure, and then persists the results http/1.0 vs http/1.1
and chunked-encoding supported somewhere. Like we already do for
passwords and ssl certificate validation.
> This should also be a clear trigger for hosting companies to upgrade
> their proxy infra.
>
>> --
>> Philip Martin | Subversion Committer
>> WANdisco | Non-Stop Data
>> www.wandisco.com
>
> Lieven
Received on 2013-06-22 10:22:58 CEST