> On Fri, Jun 21, 2013 at 9:19 AM, Greg Stein <gstein_at_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 <gstein_at_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  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
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
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
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 :(
Received on 2013-06-21 15:46:13 CEST