On Aug 16, 2010, at 1:42 PM, Paul Querna wrote: > On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski <[email protected]> wrote: >> >> On Aug 16, 2010, at 10:56 AM, Plüm, Rüdiger, VF-Group wrote: >>> >>> This basicly sums up the downsides of this approach I see as well. >>> >>> IMHO to avoid a spec violation we can only add the Expect header to >>> requests with request bodies. OTOH these requests hurt most when they >>> fail as we cannot sent the request body for a second time, because >>> we do not have it any longer available in most situations and requests >>> with request bodies are usually not idempotent. >>> >>> On the second issue we only need to take care that we do not add something >>> already there and remove something that client expects to see. >>> >>> One last thing I see is that this only works if the backend is HTTP/1.1: >>> >>> 8.2.3 >>> >>> - If the proxy knows that the version of the next-hop server is HTTP/1.0 or >>> lower >>> , it MUST NOT forward the request and it MUST respond with a 417 >>> (Expectation Failed) >>> status. >> >> Yes, the code itself is aware of the limitations of 100-Continue, >> including version and req body considerations... It's not ideal, >> but it's better than the OPTIONS method which I played around >> with earlier... >> >> Still I think it's useful to add it in, have it disabled by >> default, and see how far we can take it... > > I think the only options really are a status URL, with a regex match, > so you can test if the backend has an expected content, and having the > backends advertise/notify the proxy that they are alive. >
Well, OPTIONS is the defacto "HTTP ping" but it's also considered a "request" (afaik), and so things like keepalives, etc matter. That was the issue I ran into is that checking with OPTIONS doesn't totally remove the problem, esp for non-keepalive connections or one-shots, and then you need to worry if that last OPTIONS forced a connection that was in keepalive mode to close and all that junk.... What I just committed is not the ideal solution, but like you said, the real way to do this is non-trivial with the current architecture...
