httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: PR#1014 (request for Content-Location output header field)
Date Fri, 22 Aug 1997 00:48:29 GMT
Yeah option is fine if defaulted to off.  For anyone lurking wanting to do
this code be sure to test all the cases which go through
sub_req_lookup_{file,uri}, and test the cases which mod_negotiation
promotes to the parent request ... and test internal_redirect().  I think
that's all you have to consider.  Dunno. 

You might even be able to get away with a mod_content_location.c with a
fixup phase.

Dean

On Thu, 21 Aug 1997, Roy T. Fielding wrote:

> >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.
> 
> The attack isn't all that important.  Content-Location existed before Etag,
> which is why there is some overlap.  Also, we don't always send Etag.
> 
> >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
> >direction.
> 
> Agreed.  WebDAV is working on these issues, and is not currently using
> Content-Location for that purpose.  I haven't pressed for its implementation
> precisely because of the overhead and the lack of clarity regarding how
> it would be used.  Perhaps we could make it a configurable option, defaulting
> to off?
> 
> ....Roy
> 


Mime
View raw message