- 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>
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 UTC