On 25 Jun 2004, Joe Schaefer wrote: > Jim Jagielski <[EMAIL PROTECTED]> writes: > > > Nick Kew wrote: > > [...] > > > > It appears just to merge Set-Cookie headers in r->err_headers_out with > > > those in r->headers_out. The latter have just come from the backend > > > (the server proxied). But how/why should there be (any) cookies in > > > r->err_headers_out at this point? Presumably they'd be from the proxy > > > rather than the backend? And why merge them into a normal 2xx response? > > > > > > > This is so Cookies added my the local proxy server (Apache) via > > internal custom modules do not loose those cookies when used also > > as a proxy. If a module has added Cookie information we should > > honor that and maintain it as is. Roy and I talked about > > this and both agreed that it made sense hence the patch.
OK, on further consideration after posting, I've reached the view that the 2.0.49 patch should be modified. I'd propose to run the same transformations on Set-Cookie headers from the backend, but move the rewriting - along with the rewriting of Date and Location headers (ap_proxy_date_canon and ap_proxy_location_reverse_map) into ap_proxy_read_headers. That actually both cleans up the code (reduces adhockery) and makes it more efficient (reduces table operations), as well as making my patch orthogonal to yours. > But is the err_headers_out logic in proxy_http.c HEAD really ok? That I still find puzzling. Perhaps there's a URL into the mail archives from your previous discussion that would explain it? -- Nick Kew
