On Wed, Jul 10, 2013 at 10:41 AM, Branko Čibej <br...@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 <br...@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. Lieven > -- Brane > > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. br...@wandisco.com
