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