Re: proxies rewriting URLs

>Well, it's really a question of what should a proxy do when it
>receives a syntactically invalid Request-URI.  My preference is that
>it make no changes whatsoever to the path part of the Request-URI
>when it forwards the request.  However, this would mean the proxy
>would be sending a non-compliant request, which is also bad.

I think that it is a question of what people can encode into URIs. 
URIs do not specify a canonical form so that there can be several
URIs which logically mean the same thing.

If we are clear on the "meaning" part then two syntactic variants
of the same URI should be interchangeable. If something breaks
because of this problem then it is something which relied upon a
syntactic variation and was therefore broken.

For example I might embed <a href="http://foo.bar$"> into a document
where $ is some ambiguous character. I might know that the xyz browser 
will canonicalize differently if the URI comes from the browser or from
the bookmark file and have one of those $5million venture capital 
"companies" wrapped arround this hack (don't laugh I've seen this type of
thing more than once).

Personally I think that trying to provide support for such constructs
is ill advised. It is likely to close up options down the line. In
particular I'm thinking of HTTP-NG here. I can think of many reasons why
a proxy might choose to canonicalize URIs internally, cache matches
for one. If one considers the action of a caching proxy I think that
canonicalization of URIs in passed on requests is likely to be highly
desirable.

Since Larry reports that there are already proxies doing this sort of 
transformation I think it best to leave things as they are but include
a warning to state that problems might occur.


	Phill

Received on Monday, 11 March 1996 07:25:38 UTC