https://bz.apache.org/bugzilla/show_bug.cgi?id=65823

--- Comment #6 from Dr. Rolf Jansen <apa...@cyclaero.com> ---
(In reply to Ruediger Pluem from comment #5)
> (In reply to Dr. Rolf Jansen from comment #4)
> > Please may I ask a question?
> > 
> > I was under the assumption that the proxy module corrects the Location:
> > response header field.
> > 
> > Is that assumption correct?
> 
> Yes and no.
> It does not do anything specific to slashes, but it does changes if asked to
> via the ProxyPassReverse directive. The only thing that you should take care
> when using ProxyPassReverse is that both arguments should either end with a
> slash or not. You should not have directives where the first argument ends
> on a slash and the second does not or vice versa.

Your response put the notion of "exact match" into my head. Actually the
slashes do match, but the Location: response field of my WebDAV service does
omit the port number in case it is 80, and therefore the host element of the
URI does not match exactly the ProxyPass(Reverse) directives:

   ProxyPass             / http://10.11.0.1:80/
   ProxyPassReverse      / http://10.11.0.1:80/


Now, I changed the virtual host settings in Apache:

   ProxyPass             / http://10.11.0.1/
   ProxyPassReverse      / http://10.11.0.1/

Then I restarted Apache and the Windows WebDAV client started to work again. I
still have no idea, why it worked at the end of December last year.

> With regards to Webdav you should keep in mind that absolute URL's are not
> only passed in the Location header but also in the request / response body
> for certain methods like MOVE or COPY. This can cause issues if backend and
> frontend URL's are different since they are not rewritten on the reverse
> proxy like Location headers can be with ProxyPassReverse.

Yes, I saw this also when I investigated my present issue. The WebDAV service
in question is completely programmed by me in plain C, and so I am free to use
for the host part of the absolute URI the content of the  X-Forwarded-Host
request header field. I need to do some further tests, but it should not be too
difficult.

Thank you so much for your helpful responses. Sorry again for posting something
as a bug, which could be easily resolved by changing the setup.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to