W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

RE: Sections 3.3.1 and 5.1

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 31 May 1996 13:54:13 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960531205413Z-4941@abash1.microsoft.com>
To: 'HTTP Working Group' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, 'Ben Laurie' <ben@algroup.co.uk>


>----------
>From: 	Ben Laurie[SMTP:ben@algroup.co.uk]
>Subject: 	Sections 3.3.1 and 5.1
>
>Section 5.1
>
>'The origin server MUST decode the Request-URI in order to properly 
>interpret the request.  In requests that they forward, proxies MUST NOT
>
>rewrite the "abs_path" part of a Request-URI in any way except as noted
>
>above to replace a null abs_path with "*". Invalid Request-URIs SHOULD 
>be responded to with an appropriate status code. Proxies MAY transform 
>the Request-URI for internal processing purposes, but MUST NOT send
>such 
>a transformed Request-URI  in forwarded requests. 
>Note: This rule ensures that the form of Request-URI is well specified,
>
>to enable future extensions without fear that they will break in the 
>face of some rewritings. One consequence of rewriting the Request-URI
>is 
>that integrity or authentication checks by the server may fail. 
>Implementers should be aware that some pre-HTTP/1.1 proxies have been 
>known to rewrite the Request-URI.'
>
>Speaking as one of those responsible for maintaining the Apache proxy 
>module, I wonder about the intent of this paragraph - if a proxy is 
>permitted to rewrite, presumably to make such transformations as a/./b 
>-> a/b and a/b/../c -> a/c, then it hardly seems fair to allow the 
>server to interpret them in a different way. Is this what is intended
>or 
>are there other kinds of rewriting which it seeks to forbid?

I don't understand your question -- proxies are NOT permitted to rewrite
in any way, so the assumption of your "if" sentence is false. And the
proximate reason is so that inclusion of URLs in authentication
calculations isn't foiled by proxies rewriting the URLs (as is stated in
the note at the end of the section you quote).

Paul
Received on Friday, 31 May 1996 14:15:42 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:01 EDT