[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: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 10 Jul 2013 10:41:04 +0200

On 10.07.2013 10:20, Branko Čibej wrote:
> On 10.07.2013 05:43, Greg Stein wrote:
>> On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>>> On 09.07.2013 05:53, Greg Stein wrote:
>>> ...
>>>> For *this* project, that is absolutely the case. We have never said
>>>> "let's work against any server anybody decides to implement." We write
>>>> to our client, and our server, and third parties adapt to our changes.
>>> You can't seriously claim that and in the same breath talk about HTTP
>>> transport. We're either compliant or not. If we're not compliant, we
>>> either fix the bug or stop calling it HTTP. You cannot unilaterally
>>> decide that the HTTP spec says something else than is actually written
>>> there (and corroborated by later, albeit draft versions).
>> Huh? We're compliant. Why aren't we?
> Taking the "the client MAY ..." literally, we're compliant ... but
> there's something to be said about about following the spirit of the
> spec as well as the letter.
>
> I wouldn't really mind breaking peoples' setups if Subversion had issued
> chunked requests before, or if we'd announced well in advance that not
> supporting chunked requests is going to break something -- the way we
> did, for example, warn about the server-side effects of HTTPv2 and its
> multiple connections and many more requests. But it did not cross our minds.
>
> We'd always sold ra_serf as "ra_neon but better". So now we're faced
> with a regression that we can fix in one of two ways: lay the burden on
> each and every user that uses a site that's behind a certain kind of
> compliant proxy, or lay it on site administrators. I maintain that the
> latter is the better solution; even if it means making opening the
> session less than optimal until some 1.8.2/serf-1.4.0 combination gets
> released.

And note that we can amortize the 'less optimal' by backporting Ivan's
patch with the RA session pool in libsvn_client. Though I'm not
suggesting we do that in 1.8.1.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-07-10 10:41:30 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.