[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

From: Ben Reser <ben_at_reser.org>
Date: Tue, 9 Jul 2013 00:55:13 -0700

On Mon, Jul 8, 2013 at 9:52 PM, Greg Stein <gstein_at_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.
Received on 2013-07-09 09:55:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.