> One could do an 'OPTIONS *' request. But I am not sure if that is any better than proxy-initial-not-pooled in terms of performance.
I don't see why an OPTIONS request should not encounter problems where a GET request will. After all, the problem is on the transport layer, not on the application layer. Am I missing something ? > Or a filter could just send the first bytes of the request (less than the request line) and then do a filter flush. If that fails, repeating the request on a different connection would be ok even for non- idempotent requests, because we would know that the backend has not received the full request yet. I don't know how many errors this would catch in practice, though. This is pretty much what I stated earlier. So I assume (re)opening a connection and having the whole process of sending the request transition to that (re)new(ed) connection is possible for an input filter. I was not sure about it. Going to look into it once I have time.. On Sat, Aug 3, 2013 at 7:26 PM, Stefan Fritsch <s...@sfritsch.de> wrote: > Am Freitag, 2. August 2013, 11:21:56 schrieb Eric Covener: > > > I think this does not work for GET requests or request without a > > > request body. > > Just re-read spec, you are right -- we are abusing this in a module > > as a sort of extended handshake even w/ no body, but not against > > heterogenous backends. > > One could do an 'OPTIONS *' request. But I am not sure if that is any > better than proxy-initial-not-pooled in terms of performance. > > Or a filter could just send the first bytes of the request (less than > the request line) and then do a filter flush. If that fails, repeating > the request on a different connection would be ok even for non- > idempotent requests, because we would know that the backend has not > received the full request yet. I don't know how many errors this would > catch in practice, though. >
