On Mon, Jul 8, 2013 at 8:53 PM, Greg Stein <gstein_at_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.
Received on 2013-07-09 09:46:27 CEST