On Wed, May 04, 2011 at 02:00:33PM +0200, Sorin Manolache wrote: > > I didn't mean that I'm really clueless. I trawled through the apache > sources quite extensively and I decided to do it. And there's a > commercial/financial stake in my case too. > > If you look at mod_proxy's sources, there're 4 places in which r->main > is checked, two in ap_proxy_http_request, one in > ap_proxy_backend_broke and one in mod_proxy_ajp.c > > In the first place, If-Match, If-None-Match, If-Range, > If-Modified-Since, If-Unmodified-Since are not passed through in the > subrequest. > > In the second place, for subrequests: > > *) the connection is marked to be closed after the request > *) Content-Length and Transfer-Encoding are removed > *) the main request body, if any, is not forwarded to the subrequest's > backend. > > So if you set subreq->main to NULL you won't have the effects listed above. > > In ap_proxy_backend_broke, if r is a subrequest and the backend broke, > the main request response is marked as non-cacheable. > > I didn't look into mod_proxy_ajp.c.
Yes, but what makes me feel quite uneasy is the fact that both your solution as well as mine rely on "internal" knowledge and assumptions build on that. From a programmers point of view this is o.k. in an open source implementation but this creates administrative nightmares ... What happens iff the programmers of mod_proxy decide to change their internal processing? After all, line 426 ff. in mod_proxy.c aren't part of a published API. So, maybe years after installing your fine module, an inocent software update breaks it ... 8-/ I guess an exported mod_proxy function to fetch metadata would be a nice thing to have. Cheers, RalfD > Sorin
