RE: Specifying preference for no-content in responses

[Pablo Castro <Pablo.Castro@xxxxxxxxxxxxx>]

Thanks, this helps. Do you know of anybody that has actually implemented this?

Also, from reading the spec I got my attention back to the "expect" header that's only used to indicate that a client can handle a "100 continue" currently. Unfortunately the spec is clear that servers that don't understand any aspect of an expect header should fail the request, which makes it a no-go for a hint type of thing like what we're trying to achieve. It doesn't seem this is something that could be changed at this point even if we wanted to, but I thought I'd bring it up in case someone has explored this route before.

Thanks
-pablo

-----Original Message-----
From: Mark Nottingham [mailto:mnot@xxxxxxxx] 
Sent: Thursday, April 01, 2010 10:25 AM
To: Pablo Castro
Cc: atom-protocol@xxxxxxx
Subject: Re: Specifying preference for no-content in responses

http://datatracker.ietf.org/doc/draft-snell-http-prefer/

On 31/03/2010, at 11:25 PM, Pablo Castro wrote:

> 
> In Astoria ("OData" now [1]) we want to include entries in responses to POST/PUT requests so the server can send "fresh" values for parts of the entry or the whole thing. However, since sometimes clients may not need this and may want to avoid the extra bandwidth use, we'd like to let the client choose whether it wants a replay of the entry or just a 204 "No Content".
> 
> Content-type negotiation comes to mind, but there doesn't seem to be a possible value for the Accept header that indicates "no content please". Both a missing accept header and an empty one have meaning already. Also, as far as I know there is no content type to represent no content. 
> 
> Has anybody ran into this need where a client issuing a POST or PUT wants to indicate whether or not the server should include a fresh entry in the response? 
> 
> Thanks
> -pablo
> 
> [1] http://odata.org
> 


--
Mark Nottingham     http://www.mnot.net/