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 <b...@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
