Heya ... I'm not going to repond point-by-point. Your email covers
everything quite well. I only have a couple issues, noted below:
On Mon, Jul 8, 2013 at 9:52 PM, Ben Reser <ben_at_reser.org> wrote:
>...
> Greg's argument here mostly depends on the idea that Subversion is
> built to work against mod_dav_svn and any proxy or implementation that
> doesn't implement HTTP/1.1 with chunked requests support as
> mod_dav_svn does is busted. I find this argument very weak and
> unconvincing. Especially since this assumes that mod_dav_svn is the
> only server side implementation of our protocol. We know this is not
>
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.
We switched from entries to wc.db in WC-NG. Should we have worried that the
change would break third-parties that parsed entries? Nope.
Codeplex had some issues with our requests. Did we change our request to
get Codeplex working? Nope.
We cannot and choose not to worry about what third parties are doing. We
*do* try and keep our protocol reasonably documented, stable, and
understandable so they *can* work with us. But we've always chosen that to
be a one-way street (primarily; we have tweaked low-hanging fruit to help
third parties).
To that end, we are designed to work against mod_dav_svn. If something
interferes with our operation, then I say its *breaks* our
performance/correctness goals.
>...
> While I think it's been sufficiently proven elsewhere in this thread
> I'll make the argument that we are not HTTP/1.1 compliant if we don't
> handle this since part of my argument above assumes that we're not
> compliant if we don't handle this case.
>
Huh? RFC 2616 says:
10.4.12 411 Length Required
The server refuses to accept the request without a defined Content- Length.
The client MAY repeat the request if it adds a valid Content-Length header
field containing the length of the message-body in the request message.
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.
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.
>...
> The chair of the working group posted this:
> http://www.mnot.net/blog/2011/07/11/what_proxies_must_do
He says, " a good intermediary will pass through chunked requests such as
this one:" ... we expect chunked requests to work. When an intermediary
doesn't allow them... I call that interfering with our operation. It should
be fixed.
>...
> We limit RA serf to a max of 8 connections, but with things like
> svn:externals we open new connections and then close them, so 8 may
> not be the absolute worst case scenario.
> [[[
> #define SVN_RA_SERF__MAX_CONNECTIONS_LIMIT 8
> ]]]
>
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).
>
> We also require that we can make at least 2 connections to the server.
> So it's hard to say what the typical behavior would be across so many
> different configurations. But worst case scenario is always going to
> be number_connections_opened * round_trip_time (RTT).
>
number_RA_sessions_opened * RTT.
>
> The corporate users that Ivan is worried about that are likely to have
> no issues here because they have no such proxy in their way are the
> ones likely to have the lowest RTT.
>
> So let's say you have a RTT of 500ms, that means your command is going
> to be delayed by 4 seconds assuming 8 connections, it also means that
> you're going to have a pretty bad time using Subversion anyway. Yes
> that sucks, but I doubt very many of our commands actually make use of
> all 8 of those connections, remember we only actually require 2.
> Right now from the US I have a RTT to svn.eu.apache.org of about 180ms
> and to svn.us.apache.org of about 20ms, meaning worst case scenario
> for those is a delay of 1.4 seconds and 160ms.
>
> I have a very hard time believing that the above is worth the concern.
> We should implement this detection behavior by default.
>
Possibly. I hate telling people "you're slower because 1% of users choose
not to get their busted proxy fixed."
>
> Given Ivan's work on Serf to prefer sending Content-Length, we can
> disable it if we're built against a Serf that behaves this way.
>
> I think that we should defer from adding an option to manipulate this
> behavior until such a time that we find significant performance
> issues. Especially if down the line we're not going to need it
> because we can prefer CL.
>
I wish you guys would stop thinking that work is a panacea. That is is some
kind of grand "fix everything".
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.
We target mod_dav_svn, and chunked requests are part of our arsenal for
making the communication performant.
>...
Cheers,
-g
Received on 2013-07-09 05:54:30 CEST