On Mon, Jul 8, 2013 at 8:53 PM, Greg Stein <gst...@gmail.com> 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.
But we have said that a newer Subversion client will continue to work against an older server. The net effect of this issue is hardly different for users trapped behind these proxies from us requiring some new feature only provided in a 1.8 server to use a 1.8 client. I realize that's not entirely true since our server has always supported chunked requests, but I don't think users see this distinction. I think we owe our users to go the extra mile here. > Read that second sentence. A server (or proxy) sends a 411 at their own > peril. A client is not obligated to retry with a C-L header. I have a very hard time accepting that we're HTTP/1.1 compliant when we just throw an error at a user when they're going through a proxy that is HTTP/1.1 compliant but has chosen not to implement chunked requests. Capabilities between the client and server should be negotiated. I'd say that the RFC 2616 dropped the ball here. I understand your position that essentially we're under no obligation to try harder. But again I think we owe it to our users to do so. > We detect the busted proxy at runtime, and adapt for it. However, the test > is costly (RTT, as you note) and so we enable only upon request. Yup and I believe we haven't done a good enough job here. The option doesn't seem like a big barrier when you're applying it to a handful of machines for yourself. Scale that effort up to a user base of 20,000 users and the option stops looking like a reasonable response. Resolving the proxy may not be possible in those cases as well because the developers and the people running the Subversion servers may have absolutely no control over the proxies. They may be proprietary and not even have a way to resolve this. If you're a large enterprise this solution just flat out doesn't help you much. > Careful. A single ra_session only needs to perform the busted-proxy test > once. All connections share the result of that test. > > Problems arise with multiple sessions (think: merging). You can't assume the capabilities of one connection are equal to another. For instance if WCCP is being used to direct clients through a reverse proxy there is absolutely no guarantee that all the proxy servers in the WCCP pool have equal capabilities. You might say, that if someone does that then they're doing things wrong. But I'd say that someone implementing a large proxy setup is almost certainly going to upgrade their proxy servers at some point and they're going to do it by taking one node down, upgrading/replacing it and putting the new one back in the pool. So that they can maintain continuous uptime and their capacity. I know we're probably caching this on the ra session, but that's probably wrong. In practice that's probably not going to cause problems for very many people, but it's still wrong. > Possibly. I hate telling people "you're slower because 1% of users choose > not to get their busted proxy fixed." So do I. But I want a fix that doesn't ask our users to jump through hoops. > Chunked requests are *good* for us. We *want* chunked requests. It gives us > flexibility in our design where C-L does not. We can generate requests where > we don't know the length ahead of time. There are two main areas where that > is very important: > > 1) custom request buckets that dynamically generate the request on demand > (via callbacks into other parts of svn) > > 2) applying gzip and other encodings on the request > > Using C-L completely denies these capabilities. I realize you're thinking long term here Greg, but I'm thinking short term. We're not using these things right now. We don't need chunked requests. So let's solve our users immediate issues by turning off chunked requests. Then let's figure out a performant way of detecting when we can use chunked requests safely. If we can do that then people using these proxies without chunked requests will probably end up with less performance, but we can add a note to our release notes telling people to look for this and make sure this isn't happening to get the best performance. I agree that chunked requests are very good for us. But I want to do it in a way that is maximally compatible without making our users jump through hoops. If Ivan's work on the Serf side isn't sufficient to get us there then let's do what's needed to get us there.
