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. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
