Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

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.

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com