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

Re: HTTP at a glance

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 28 Feb 2012 23:54:37 +0100
Message-ID: <4F4D5B2D.1060807@gmx.de>
To: Amos Jeffries <squid3@treenet.co.nz>
CC: Martin Thomson <martin.thomson@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>, ietf-http-wg@w3.org
On 2012-02-28 23:16, Amos Jeffries wrote:
> On 29.02.2012 07:31, Martin Thomson wrote:
>> On 27 February 2012 13:23, Roy T. Fielding <fielding@gbiv.com> wrote:
>>> No, POST can create resources.  The only difference is that the
>>> client doesn't
>>> know how the resource(s) will be identified after being created.
>> And some of us really like having some control over our own URI space,
>> preferring this approach over PUT. I wouldn't characterize that as a
>> mistake, just a choice.
> The blessed way to do that is with a 3xx redirect instructing the client
> where you want the resource PUT if they somehow get it wrong. (Or just

I wouldn't call it "the blessed way". In particular, automatically 
following a redirect upon PUT might be dangerous.

> plain denying wrong PUT if you dont want third-party scripts using PUT
> on your site.)

Yes. If you want to control the URI space, simply do not implement 

> Yes, I too see a bandwidth problem with that blessed way of doing
> things. Perhapse what is needed is a response indicating "okay, but
> change the URI to X" which does not involve a repeated PUT action. The
> plain PUT+200 sequence seems not to do that easily (workable ideas
> welcome. With my web-dev hat on I have an interest in implementing).

So you want PUT semantics with server-chooses-URI? I tried to specify 
this a few years ago 
but was "convinced" that POST is sufficient, so defined the 
WebDAV-specific RFC 5995.

Best regards, Julian
Received on Tuesday, 28 February 2012 22:55:15 UTC

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