- From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
- Date: Thu, 31 Aug 1995 04:35:12 +0200 (MET DST)
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel Kaphan writes: > Proposals for additional language in the HTTP 1.1 spec. > > In section 8.19: > > To address the security hole that Larry Masinter recognized: > > "If a Location response header is returned with a 2xx response, > the location must be on the same server as the request-URI. > If a cache or user agent receives a 2xx response containing a Location > response header with a location on a different server, it should > disregard the Location header." ^^^^^^^^^ maybe better to say discard? A client located behind a non-IP-forwarding firewall may not have access to internet DNS to validate the host part, while the proxy serving it must be able to do the validation! > > To inform cache and user agent implementors of the significance of the > Location header in 2xx responses: > > "If a cache or user agent receives a 2xx response containing a > Location header, it should use the location designated by this header > as the cache key for the returned resource, and should not use the > request-URI for this purpose." Hmm. It's a good question: the cache key extracted from the location header is an additional or a replacement one? The right answer to this question may depend on accept request headers! (And an additional question: how can a client or a cache detect, that the accept headers are in effect or there is only one URL (file) behind the request URL? Scripts may be hidden behind virtual paths, and may return any entities avaliable from the origin server and even other (http or other) servers.) Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Wednesday, 30 August 1995 19:51:42 UTC