Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 41698]  - Site documentation of Header edit is
 missing
In-Reply-To: <bug-41698-7868@http.issues.apache.org/bugzilla/>
Message-Id: <20070330080844.94812714066@brutus.apache.org>
Date: Fri, 30 Mar 2007 01:08:44 -0700 (PDT)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41698>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41698


------- Additional Comments From rea-asf@codelabs.ru  2007-03-30 01:08 -------
Ruediger, good day.

(In reply to comment #14)
> Many thanks for your continued work on this. Sorry, I guess it is my fault that
> I did not explain the problem clearly enough. To be honest I have not looked at
> your patch in detail now, but however perfect it may be for the mod_rewrite case
> it will not fix the problem, because mod_rewrite is only *one* module that could
> break. The final solution needs to deal with *any* module that adjusts the
> original uri during request processing, so even third party modules and modules
> that have not been written yet.

The problem is that the modules are rewriting the URLs differently. And there is
no generic way to tell how. For example, ap_proxy_http_request can rewrite the
'Destination' header for the mod_proxy's own rewriting, but it will completely
fail to do it for the mod_rewrite's rewriting: it has no knowledge about the
rewriting rule that were used. And in the case of *any* module that uses
mod_proxy rewriting hooks, there is absolutely no way to get the proper
rewriting of the 'Destination' header. And, I think, it is the module's matter
to rewrite all headers properly. Why should mod_proxy care of mod_rewrite's (or
whatever module's) internals?

> But digging somewhat deeper I noticed that since 2.2.x the Destination header
> gets rewritten in the same way as the Location header. So you can configure this
> properly via ProxyPassReverse (which you need to do anyway to get the redirects
> fixed). Of course there is still a documentation bug as the documentaion of
> ProxyPassReverse fails to document this behaviour.

Yes, but it is rewritten when the request is passed from the backend server to
the main one, that is the ProxyPassReverse is about, isn't it? And I am talking
about the header rewriting on the 'main server' -> 'backend server' path.
Because if the backend DAV server sees the wrong 'Destination' header, it just
refuses to serve the request. And the funny thing: the 'Destination' rewriting
for the ProxyPassReverse is implemented just for the mod_proxy as well. Why it
will be worse to implement the 'Destination' rewriting only for two major
modules dealing with proxying, mod_proxy and mod_rewrite just now, and leave
other consumers of rewriting routines in mod_proxy to get it rewritten by
themselves or say that they are failing in the case of DAV proxying?

Talking about DAV checks: currently, the Apache's mod_dav checks
(/modules/dav/main/util.c:204 from the snapshot httpd_20070330041747.tar.gz)
only for schema and port coincidence, so we can do the generic rewrite and this
can help for some easy cases. But is the backend DAV server is not Apache, or if
we're rewriting not only the host, port and protocol, but some path components,
then we're lost. So I see not way to implement the rewriting in a generic way,
and, to be honest, I see no reason for it: it is up to the module's author.

Any comments?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org