[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Fri, 21 Jun 2013 17:45:19 +0400

> 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 [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
Received on 2013-06-21 15:46:13 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.