Re: Sections 3.3.1 and 5.1

jg@w3.org wrote:
> 
> >
> >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!

Its just that I've tangled with NTP recently ;-)

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

Agreed.

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

My point was that if the proxy can rewrite, it rather breaks the idea of 'to
enable future extensions without fear that they will break in the face of some
rewritings.' It should be clear what rewritings are valid in a proxy, and if
they are valid in a proxy, surely they must be valid in the URI? I guess
similar concerns apply to caches in general. In fact, it is the caching nature
of most proxies that really concerns me.

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

Ummm ... not in my version (ver81.doc). But it didn't affect my understanding.

Cheers,

Ben.

> 				- Jim
> 
> 				

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Received on Friday, 31 May 1996 14:21:05 UTC