- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 5 Feb 2008 07:33:04 -0500 (EST)
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Mark Nottingham <mnot@mnot.net>, Brian Smith <brian@briansmith.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
On Tue, 5 Feb 2008, Julian Reschke wrote:
> Yves Lafon wrote:
>> I agree that even a GET might have side effects, but no "direct" ones. By
>> "direct" I mean relative only to the processing of the HTTP request by the
>> resource. ie: doing a GET on a resource X may generate a log entry (and
>> this log entry may be addressable), but it's a global server action not a
>> resource one.
>
> So what kind of side effect would be updating a hit counter GIF? Or updating
> a list of "top referrers"?
If the resource triggers the modification, then GET is misused, if it's a
server configuration (filter, automatic log analysis), then the resource
is not responsible for those side effects.
>>> - a 201 response informs the client that "a" resource has been created
>>> (maybe more)
>>> - a Location header informs the client of the URI of this new resource (if
>>> missing the URI is the one of the request???)
>>
>> As the URIs should be in the entity of the response, the logic of !Location
>> => request URI is wrong.
>
> Disagree. Why would you send a Location header for a successful (initial) PUT
> to a URI? Remember:
>
> "The Location response-header field is used to redirect the recipient to a
> location other than the Request-URI for completion of the request or
> identification of a new resource." --
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>
I know about the definition of Location, but here we are not redirecting,
just indicating the URI of the main newly created resource, and it can be
done by only exposing it in the response entity (there is no MUST there).
>
>>> - a ETag header on the response indicates the current value of the entity
>>> tag for this requested variant (request uri or location)
>>
>> How does an ETag sent with a 201 differs from one sent with a 200 and a
>> Content-Location?
>
> It should never differ, and only depend on the Request-URI + those request
> headers that select the variant.
But in this case it may apply to another URI than request URI...
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Tuesday, 5 February 2008 12:33:12 UTC