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. -- Philip Martin | Subversion Committer WANdisco | Non-Stop Data www.wandisco.com
