www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois-Rene Rideau <f...@tunes.org>
Subject Re: URI lossage with ProxyPass
Date Thu, 24 Jun 2004 12:45:23 GMT
On Thu, Jun 24, 2004 at 01:19:09PM +0100, Nick Kew wrote:
>> Can anyone see any reason why a proxy request should have the URL changed?
> 
> For a forward proxy, that's right.  For a reverse proxy, no.
> Of course ProxyPass and family modify URLs.
OK, I mean, "changes that require further canonicalization".
And why does that further canonicalization require to de-encode anything?
If de-encoding there must be because of intermediate modifications,
shouldn't there be a preliminary encoding in an early pass to preserve
the encoded parts of the original URI?

> Faré: do you have a testcase that demonstrates this?
Try any URI with a %3A, and any URL with a %2F inside. 100% reproducible.
i.e. try to access through ProxyPass the following URI:
  http://cliki.tunes.org/CP%2FM
  http://cliki.tunes.org/Word%20Processors%3A%20Stupid%20and%20Inefficient
For instance add a
	ProxyPass /cto/ http://cliki.tunes.org/
to one of your servers, and see (e.g. with tcpdump
or by logging proxy behaviour) what happens.

The real cliki.tunes.org actually sits behind a (now fixed) apache proxypass
that takes care of handling HTTP problems with bad clients and bad connections.
Without the fix, these two pages (created before the use of apache)
were unaccessible, each in a different way.

> I'll be committing
> my fix to bug 10722 soon, and if I'm satisfied with your patch I could
> probably roll it in together.  A testcase will help there:-)
nagoya.apache.org is unaccessible right now,
so I can't see what 10722 is about.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
If it isn't source, it isn't software.
	-- NASA

Mime
View raw message