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?
> Yes, we've come across broken proxies any number of times; but the
> refusal to accept chunked transport in HTTP/1.1 is clearly not broken
> since its anticipated and described by the HTTP spec.
From our perspective, somebody broke our communication to mod_dav_svn.
Are they allowed to? Sure. They return a 411 like the spec says. And
following that spec, we choose not to resend with a C-L header.
The proxy is not inherently busted, per the spec. But it certainly
busted our communication.
> And it is definitely not OK to make our users collateral damage in a
> crusade against "busted" proxies. It's fine to print a big fat warning
I'm fine with the users argument. Never said otherwise.
I said, "I don't want the 99% to suffer at the hands of the edge
case." And especially because the edge case is usually solvable. (and
yes, I know; I said "usually")
I can agree this is a regression. We run into regressions in every
release. We don't even bother to solve all of them (ref: api-errata).
To that end, is "yeah. sorry. regression in 1.8. there is a knob to
fix it." an improper response?
I'm not really sure of the answer to that. But I think it's a fair question.
Received on 2013-07-10 05:43:58 CEST