Maybe I didn't describe the global picture, sorry.
There are obviously known headers that will never contain a URL, like
the "Date" you mentioned, and several others.
However, you may have other headers containing the host URL, like
"Destination" for the WebDAV protocol.
So, I was asking to check every header (we may potentially discard known
ones, but that's an optimization) for the proxy/back-end URL, and fix it
if needed.
Concretely, when using WebDAV, you can copy a file from one location to
another; the client sends a "COPY" command on a URI "/dir/file", and
sets a "Destination" header to - in my example -
"https://proxy/newdir/newfile";.
The WebDAV server refuses this because it receives a command to copy
from "http://back-end/dir/file"; to "https://proxy/newdir/newfile";.
I personally have the problem with WebDAV, which is obviously a common
one because of the standard, so we could fix only that header; but I
imagine some other applications could use the same mechanism, so why not
generalizing this to all headers ?
Excepting the little overhead, I find this a very robust solution. I
don't think it breaks anything, so I would not see it as a behavior
redesign.
Nick Kew wrote:
On Wed, 03 Oct 2007 12:11:09 +0200
Nick Gearls <[EMAIL PROTECTED]> wrote:
Hi,
I think mod_proxy should be enhanced/fixed in some way:
- If I use ProxyPass & ProxyPassReverse to forward connection from
"proxy" to "back-end", ProxyPassReverse adapts the "Location" header
from "back-end/..." to "proxy/...".
1. Why only the "Location header" ?
Because that's the only header you had that contained the string
"back-end" with URL semantics.
2. In case you access your proxy in HTTPS, and your back-end in HTTP,
ProxyPassReverse should also remove the protocol from all headers
3. ProxyPass should do the same for all headers - fixing the
protocol, and possibly the host if "ProxyPreserveHost" was not used
How would you propose to rewrite, for example, the "Date" header?
Does it sound sensible ?
I expect if you think through what you're asking, you'll eventually
redesign the existing behaviour. If not, tell us what's wrong.
