Re: HTTP at a glance

Julian Reschke <julian.reschke@gmx.de> Tue, 28 February 2012 22:55 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217E321E8044 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Feb 2012 14:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.259
X-Spam-Level:
X-Spam-Status: No, score=-8.259 tagged_above=-999 required=5 tests=[AWL=2.340, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEMLWCu2HyIn for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Feb 2012 14:55:39 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6021E802C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 Feb 2012 14:55:39 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1S2Vx7-0002B9-Mb for ietf-http-wg-dist@listhub.w3.org; Tue, 28 Feb 2012 22:55:25 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1S2Vww-0002AC-Vk for ietf-http-wg@listhub.w3.org; Tue, 28 Feb 2012 22:55:15 +0000
Received: from mailout-de.gmx.net ([213.165.64.23]) by lisa.w3.org with smtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1S2Vwu-0004ch-Te for ietf-http-wg@w3.org; Tue, 28 Feb 2012 22:55:14 +0000
Received: (qmail invoked by alias); 28 Feb 2012 22:54:44 -0000
Received: from p3EE2676A.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.103.106] by mail.gmx.net (mp035) with SMTP; 28 Feb 2012 23:54:44 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18TbBk/o9MTEC0aapqa9+SwX0QzK6jx0s0zewSnWe USr5nbm7+zG3uJ
Message-ID: <4F4D5B2D.1060807@gmx.de>
Date: Tue, 28 Feb 2012 23:54:37 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
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
References: <4F4AA9D9.5040000@informatik.uni-kiel.de> <4F4B5BFD.2030701@treenet.co.nz> <2C531B17-7035-490E-894C-30D4A67B8F2F@gbiv.com> <CABkgnnU7-7wLf0F7n_LvC4O9gM2hkpUOa7uYwOp9NrZFqHPWQw@mail.gmail.com> <29e829a75da6a761cd2c2f8af7c45a96@treenet.co.nz>
In-Reply-To: <29e829a75da6a761cd2c2f8af7c45a96@treenet.co.nz>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1S2Vwu-0004ch-Te 073b9d173cbdba3751b13da32714a9b9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP at a glance
Archived-At: <http://www.w3.org/mid/4F4D5B2D.1060807@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/12612
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1S2Vx7-0002B9-Mb@frink.w3.org>
Resent-Date: Tue, 28 Feb 2012 22:55:25 +0000

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 
PUT-for-create.

> 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 
(http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html) 
but was "convinced" that POST is sufficient, so defined the 
WebDAV-specific RFC 5995.

Best regards, Julian