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. AFAIK, we don't do a good enough job on the first approach, and this is how many commercial load balancers test if a destination is alive. The second approach is done with the heartbeat code, though it would be nice to support it without requiring multicast. (ie backends ping the frontend at a specific URL) Both of these are painful to handle inside a request cycle -- ideally they would be handled outside blocking any single request from finishing or processing. Doing this week inside the request cycle just seems out of place. I guess mod_proxy_x could fork() off a child like mod_cgid and then check backend statuses asynchronously to requests, but thats a mountain of work :)
