W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Tue, 05 Feb 2008 14:20:01 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Jamie Lokier <jamie@shareable.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1202217601.17924.28.camel@hlaptop>

tor 2008-01-31 klockan 09:55 +1100 skrev Mark Nottingham:

> I find this just plain weird. On POST responses, it implies that you  
> can negotiate for response headers on another resource and get them  
> tunnelled back in the current response. If there's a Vary header  
> present, does it apply to that resource too? If not, how do you know  
> what the requested variant really was?

Content-Location, except that you can not blindly trust it due to
security implications... and we have already agreed that URIs indicated
by Content-Location SHOULD NOT be subject to server driven content
negotiation. Layering content negotiation ontop of those quickly leads
to recursive madness.

> On PUT responses, it's a little more sane, but the language forces the  
> requested variant to be the same as that just created; i.e., if  
> there's a chance of conneg, the Accept-* headers have to be set in  
> lockstep with what you're PUTting. So, you'd better not set Accept- 
> Encoding: gzip unless the request entity is also content-coded with  
> gzip, and AFAIK many implementations will have problems here, because  
> these mechanisms tend to be taken out of developers' hands.

It's the same in both as both may create a resource at a location
different than the requested URI. Even more obviously so in case of POST
than PUT as the request-URI of a POST is a data processing agent.. but
the principle on what is the actual created resource location is about
the same for both..


Received on Tuesday, 5 February 2008 13:22:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC