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

Re: Sections 3.3.1 and 5.1

From: <jg@w3.org>
Date: Fri, 31 May 96 16:54:04 -0400
Message-Id: <9605312054.AA05266@zorch.w3.org>
To: Ben Laurie <ben@algroup.co.uk>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
>
>Date:  Fri, 31 May 1996 20:03:57 +0100
>From:  Ben Laurie <ben@algroup.co.uk>
>To:  HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
>Subject:  Sections 3.3.1 and 5.1
>
>Section 3.3.1
>
>Strictly speaking Universal Time (which I think is actually UTC, not UT) 
>is _not_ the same as GMT - they are guaranteed to be within 0.6s of each 
>other.
>

Arghh.. and I used to do Astronomy for a living.  The trivia that some
people remember!  I think I'll remove all reference to UT, and
just talk about GMT, and let Jeff Mogul worry about if there are
any consequences to caching when leap seconds
occur to keep the time in sync with the earth's slowing rotation...


>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?
>

The intent is that, while you may rewrite abs_path internally to your
heart's content, you can't forward the rewritten abs_path to the origin server.
This ensures that the origin server always gets exactly what the client
sent for abs_path, for the reasons specified in the note.

I did add an paragraph break before "In requests that they forward",
as it is clearly proxy requirement independent of the previous sentence.
				- Jim

				
Received on Friday, 31 May 1996 13:59:44 EDT

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