- From: Balint Nagy Endre <bne@carenet.hu>
- Date: Mon, 29 Apr 1996 12:40:15 +0200 (MET DST)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Koen Holtman: > Here is new text for the Content-Location section. The change-bars > are computer-generated. These changes reflect the removal of spoofing > mechanisms from the spec, and also fix some terminology. To Jim > Gettys: please perform the edits indicated below as soon as you can. > > --snip-- > > 10.16 Content-Location > > The Content-Location entity-header field is used to define the > location of the specific resource associated with the entity enclosed > in the message. A server SHOULD provide a Content-Location if, when > | including an entity in response to a GET request on a varying > | resource, the entity corresponds to a specific location which can be > accessed via the Content-Location URI. A server SHOULD provide a > Content-Location with any 200 (OK) response which was internally (not > visible to the client) redirected to a resource other than the one > identified by the request and for which correct interpretation of > that resource may require knowledge of its actual > | location. [##sentence deleted here##] This may cause the false sense of Content-Location applicable only to varying resources, however there are good reasons to use it for simple URIs: URIs http://src.doc.ic.ac.uk/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://sunsite.doc.ic.ac.uk/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://phoenix.doc.ic.ac.uk/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://146.169.43.1/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://155.198.191.4/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://193.63.255.1/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://146.169.2.10/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://146.169.16.11/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://146.169.17.5/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://146.169.32.5/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://146.169.33.5/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt http://155.198.1.40/computing/internet/internet-drafts/draft-ietf-http-v11-spec-02.txt identify the same resource. (Its worth mentioning that internet-drafts have a lot of URIs on different servers, but that problem will be addressed by URNs hopely in the near future.) I guess the official name of the http server is 'src.doc.ic.ac.uk', and clients (and caches) should use that name, but we cant be sure, unless the server says that (using Content-Location). Storing under 12 keys the same resource isn't economic, we need a possibility to spare that disk space! For other protocols the 12 variants of the internet host reference is the same, but for http (since Host:) may have different meaning. How should a client determine that the server in question deesn't hosts virtuals servers? (Entity header comparison for every URL isn't enough effective, but works.) Perhaps we should add some header declaring that the server does host virtual servers? Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Monday, 29 April 1996 03:58:28 UTC