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

RE: I-D Action:draft-snell-http-prefer-03.txt

From: Thomson, Martin <Martin.Thomson@commscope.com>
Date: Wed, 30 Mar 2011 12:58:34 +0800
To: Cyrus Daboo <cyrus@daboo.name>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "Roy T. Fielding" <fielding@gbiv.com>
CC: Mark Nottingham <mnot@mnot.net>, httpbis mailing list <ietf-http-wg@w3.org>
Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B9559@SISPE7MB1.commscope.com>
On 2011-03-30 at 05:14:11, Cyrus Daboo wrote:
> Hi Poul-Henning,
> 
> --On March 29, 2011 10:12:34 AM +0000 Poul-Henning Kamp 
> <phk@phk.freebsd.dk> wrote:
> 
> >> The goal seems to be to ask for the server's result of a PUT or 
> >> POST to be returned as part of the same action instead of requiring 
> >> the client to make an additional GET request.
> >
> > And standardizing a header to kindly request but not demand this, 
> > would help how ?
> >
> > Is the hope that all browsers will send this by default ?
> 
> Browsers are not the only HTTP clients around.
> 
> In the CalDAV (RFC4791) world we do have servers immediately modifying 
> data PUT by clients with the requirement that clients then have to 
> immediately do a GET. This happens because the server typically does 
> take immediate action to do some form of scheduling - that may simply 
> be to add an indicator to the data that a scheduling operation is 
> pending (and that operation then happens asynchronously). Avoiding the 
> extra roundtrip would be beneficial in this case particularly as 
> mobile devices make use of this service.

Having a PUT and GET merged sounds like a useful idea.

There's an inherent assumption in this that I don't think you've considered.  The response to a PUT might already be an entity with some purpose (e.g. feedback about the change of a different nature).  For one, that means that - unlike a regular GET - the entity in the response cannot be assumed to be a representation of the resource.  That doesn't mean that you can't merge the two, but I'd have to suggest a specific indication.  It might be as simple as setting Content-Location.

--Martin
Received on Wednesday, 30 March 2011 04:59:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT