On Sat, Jun 22, 2013 at 10:07 AM, Lieven Govaerts <svn...@mobsol.be> wrote: > On Sat, Jun 22, 2013 at 9:08 AM, Philip Martin > <philip.mar...@wandisco.com> wrote: >> Ivan Zhakov <i...@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
