httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: PR#1014 (request for Content-Location output header field)
Date Thu, 21 Aug 1997 05:21:07 GMT
On Wed, 20 Aug 1997, Roy T. Fielding wrote:

> It shouldn't hurt for anything (it will not be visible in bookmarks
> or URL boxes in any case).  The main thing that it would be used by
> is remote authoring tools, in theory at least.

Ok Apache can possibly generate Content-Locations.  There are certain
cases where sub_req_lookup_file is used to access an object for which the
server cannot possibly form a URI.  But they probably don't affect
Content-Location generation.

The original submitter wanted Content-Location so that caches could do
very dubious things with it.  On another reading of the spec I can't see
that Content-Location gives a cache anywhere near as much flexibiliy as
ETags do.  I just think the possibility of caches getting things wrong
with C-L is just way too huge ... I know that section 13.10 warns against
a really obvious attack involving C-L, but I still worry about it.

But what's missing for an authoring system is a method of getting a list
of the variants for the purposes of editing ... so I still don't see how
useful it is.  Although response code 300 looks like it could head in that

If at the time of a GET the server knew it was a request from an authoring
system then it could return 300 (or otherwise list variants)  and the
client would know the exact list of options ...  (i.e. an authoring system
should perhaps send an EDIT request when it wishes to edit a document,
possibly do a multiple-variant dialogue, then issue a PUT when the user is
done editing.)

I dunno, I don't feel particularly inclined to implement C-L... it's a lot
of bytes to send over the wire on every request which apply to very few
end users.  Maybe others feel differently though. 


View raw message