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? > 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. >... Cheers, -g
