On Mon, Jul 8, 2013 at 9:52 PM, Greg Stein <gst...@gmail.com> wrote: > If you're going to vote this way, then I think you need to say what would > solve the issue for you. We probably don't want to play "bring me another > rock".
I'm pretty sure that Daniel would accept my suggestion in the other thread of [[[ I'd suggest http-detect-chunking with a description of "Detect if the server supports chunked requests. This may be necessary for use when a proxy does not support chunked requests. By default this is off because mod_dav_svn always supports chunked requests and detection of this hurts performance." ]]] > Note: I see the term "busted" is from svn's point of view, NOT the protocol > definition, and since this is *our* config, then it is entirely reasonable > to use that point of view. That's not what you've been arguing at all until now. You've been arguing that chunked requests is in the HTTP/1.1 spec and they're required to implement it. But even this point of view argument isn't valid. Because the proxies are actually busted from Serf's point of view because Subversion prior to Serf had no problem with these servers. We've made the decision to switch to Serf because it has some benefits, one of which is chunked requests. Telling users that their proxy is busted from our point of view when it worked just fine with 1.7 doesn't go over very well with users. As Kevin rightly pointed out, users really don't care that you think every HTTP/1.1 server should be implementing chunked requests. > Consider: what if the server responded 501 to every MERGE request? That > meets the protocol definition, but it is absolutely busted from svn's point > of view. That's not a reasonable comparison at all. There is absolutely no way to resolve that on our end. Yes we expect that the DAV/DeltaV methods work. There is a world of difference between requiring some functionality to work that we've never worked without before and requiring an optional feature of HTTP/1.1 work when we haven't required it up until now and the HTTP/1.1 standard is essentially telling you that you really should avoid using the feature unless you have to use it. We have a working patch that detects this issue by sending an extra request and then turning off chunked requests so we don't have to use this. When we add new functionality to our servers and clients we negotiate what we can use. A 1.8.x client continues to work against a 1.7.x server even though some of the features on the server end a 1.8.x client might want to use. This should be absolutely no different. Have we considered just turning off chunked requests entirely until Serf has a fix to automatically detect and handle servers that don't support chunked requests? I've seen a lot of discussion about the cost of doing an extra round trip to detect if we can use chunked encoding, but I haven't seen anyone comparing the performance of the client with and without chunked requests.
