On Sat, Jun 22, 2013 at 5:17 PM, Johan Corveleyn <[email protected]> wrote: > On Sat, Jun 22, 2013 at 11:12 AM, Lieven Govaerts <[email protected]> wrote: >> On Sat, Jun 22, 2013 at 10:24 AM, Johan Corveleyn <[email protected]> wrote: > ... >>> Maybe I'm missing something, but why would you downgrade to HTTP/1.0 >>> only because of the 411 (Content Length Required)? Can't you just >>> continue using HTTP/1.1, but use CL instead of chunked requests? Or is >>> falling back to HTTP/1.0 just the quickest solution within the current >>> implementation? >> >> There are only 2 differences between 'http 1.0 mode' and 'http 1.1 >> mode' in ra_serf. First is using Content-Length instead of chunked >> encoding. The second is that the Connection:keep-alive header is set >> on all responses.
Hmm. We should probably stick with the Keep-Alive even on 1.0 requests. Some proxies understand that. >> I actually expected a third difference, pipelining should be disabled >> in http 1.0 mode via set_max_outstanding_requests call, but I don't >> see that in the code. gstein? HTTP/1.0 can do pipelining, so I see no reason to disable that. >>> IIUC HTTP/1.1 has other advantages besides chunked encoding, and can >>> be used perfectly well without it. So it seems you can fall back to >>> HTTP/1.1 + ContentLength here, no? Right. We could use compression, for example. (iirc, 1.0 doesn't have that) >> Yes, that's indeed possible. It does add yet another variant of >> communication though. IMO we already have more options than we can >> support, we should cut down in the multitude of ways we support legacy >> systems. I'm thinking we just have two flags: http10 (aka "don't know whether the server is 1.0 or 1.1") and "disable_chunked_requests" (or some shorter name). >... >>>> This will add one round-trip of overhead for every serf session, and >>>> it impacts all users, even those that are not behind such (outdated) >>>> proxies. If you send a second request, then I'd suggest just repeating the OPTIONS rather than a PROPFIND. It will be much easier on the server. >>>> I'd support making this dependent on a 'http1.0_server" option in the >>>> servers runtime configuration. With this option it only impacts those >>>> users that are working behind outdated proxies. We can include the >>>> necessary instructions for users in the error description of the >>>> by-default-unexpected 411 response. >>>> >>>> This should also be a clear trigger for hosting companies to upgrade >>>> their proxy infra. The flag could be something like "busted-proxy = on". When you start seeing blog posts like "In order to checkout from EXAMPLE.COM, you must set busted-proxy=on in your .subversion configuration", and that gets back to EXAMPLE.COM ... you can bet they'll dig into the problem and fix it :-) [ as an aside, I complained to an svn hosting company that their proxy config broke serf; they were in transition and accidentally busted it; they had it fixed a few days later ] I would be in favor of instructions on how to fix these 411 errors, then have the user set the flag and try again. Now: the failure mode when the server *does* fix the flag, is a second OPTIONS is sent when it doesn't need to be. Not a horrible problem. >>> I'd favor always auto-detecting, even at the cost of the extra >>> round-trip. Or perhaps make the default auto-detection, and have a >>> flag to shortcut the auto-detection if you know what you're doing. >> >> That'd be the 'http1.0_server' flag, or the cached flag I've mentioned >> in my other mail. > > I'm not really fond of a runtime config flag for this, but then again > I'm also not fond of forcing the extra roundtrip for all users on the > account of these wonky proxies (which I suppose are really a small > minority). We should *not* send an extra request, unless the user specifically instructs us to. In a properly-working environment, it would not be needed. That is our typical and ideal situation. Users/admins will need to compensate for their broken setup. It isn't really our problem, but we'll help a little (a flag) for them to work through it. > The cached flag sounds to me like a risky solution (in the sense that > it may become a source of bugs and strange behavior). What if a proxy > gets upgraded (or configuration changed, for better (enabling chunked > encoding) or for worse (disabling it))? How will the cache be > invalidated? If it's not invalidated in some automatic way, a client > that has "use 1.0" cached for a particular server will continue using > HTTP/1.0 forever, even if the server / proxy gets upgraded, ... If > it's the other way around, the user will suddenly start getting errors > (so the error message still better point out the "manual override" or > "clear cache" switch). I'd suggest runtime checking (a second OPTIONS) based on a user setting, or a cached flag. If we find that the host suddenly starts supporting chunked requests, then we can clear the cache. We could even warn the user "you set busted-proxy, but it appears to be working now; you may want to clear that flag". > At the moment I don't have any better ideas though. Perhaps we / you > should wait a little more for other people to give their opinion or > suggestions about this? > > How about Kevin's suggestion [1], that serf should ideally be using CL > instead of chunked-encoding for the requests? As a default? Absolutely not. In a future serf where we change the bucket model to include a "getsize" method, then we could use C-L when the bucket reports a known/fixed size. Some buckets may not be able to do that, of course, and we defer to chunked requests. Ideally, ra_serf should be implementing some custom buckets, corresponding to different types of requests it makes. We could dynamically build the request, which would (typically) be much more efficient (on-demand/lazy reading and lower memory overhead). Cheers, -g
