> On Fri, Jun 21, 2013 at 9:19 AM, Greg Stein <gst...@gmail.com> wrote: >> Please revert this. You *cannot* rely on a 411 response. >> >> You are also not allowed to send a 1.1 request to a server for which >> you don't know if they support 1.0 vs 1.1. >> On Fri, Jun 21, 2013 at 5:28 PM, Greg Stein <gst...@gmail.com> wrote: > This has been quoted before, but I'll repeat it again. RFC 2145, Section 2: > > "One consequence of these rules is that an HTTP/1.1 message sent to an > HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be > constructed so that it remains a valid HTTP/1.0 message when all > headers not defined in the HTTP/1.0 specification [1] are removed." > > Removing the Transfer-Coding: chunked header completely alters the > message. Thus, it cannot be sent to a 1.0 server. This is why you > cannot rely on any particular behavior or response status.
Hi Greg! Thanks for review. My patch doesn't rely on 411 response only: ra_serf will downgrade to HTTP/1.0 if *any* HTTP/1.0 response received *or* HTTP/1.1 411 status code. I've tested several browsers and they use HTTP/1.1 as first request. >> Sigh. Seriously, man. This is completely counter to the work that was >> done. We *start* with 1.0, and then we upgrade to 1.1 only when the >> server identifies that it can handle it. Not to mention the >> complications of intervening proxies. You're making a mess of that >> work. >> 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 :( -- Ivan Zhakov
