[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: Lieven Govaerts <lgo_at_apache.org>
Date: Wed, 10 Jul 2013 10:53:14 +0200

On Wed, Jul 10, 2013 at 10:41 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> 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.

That patch doesn't work yet, but it's a good example of the many other
optimisations we can still do in ra_serf performance.
(Also) Ivan's work on reusing SSL sessions between connections in the
same SSL context should also help a lot, but that's for https only.


> -- Brane
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane_at_wandisco.com
Received on 2013-07-10 10:54:09 CEST

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