Re: The document's address

"Roy T. Fielding" <fielding@gbiv.com> Fri, 18 January 2013 12:25 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 A6FA821F888A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 18 Jan 2013 04:25:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuVF5nU-p7vi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 18 Jan 2013 04:25:05 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 25D8A21F84D8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 18 Jan 2013 04:25:05 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1TwAz7-0005yB-Kp for ietf-http-wg-dist@listhub.w3.org; Fri, 18 Jan 2013 12:23:49 +0000
Resent-Date: Fri, 18 Jan 2013 12:23:49 +0000
Resent-Message-Id: <E1TwAz7-0005yB-Kp@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1TwAz2-0005wh-N5; Fri, 18 Jan 2013 12:23:44 +0000
Received: from caiajhbdcagg.dreamhost.com ([208.97.132.66] helo=homiemail-a67.g.dreamhost.com) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <fielding@gbiv.com>) id 1TwAz1-00020u-JW; Fri, 18 Jan 2013 12:23:44 +0000
Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 04F6027BC064; Fri, 18 Jan 2013 04:23:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=CigcP7ytN30Guugc8GW3BeD783Q=; b=JiUeZxDB2jyTD4cXckQ1bwFqttBK 0BUqoCvlqsnYq/lgpamZb+05oPPtEC0IIOGP7TEW6CSDBuS029LSLVn+HDtOy0wJ O2zTDhmzNGTCy61AA3tbRhfuBwc9hQlhkHmPmt6IvPXsu6ScBZ//LPBT02HLo2BW 6p3BaHhfgeWu8kQ=
Received: from [192.168.1.84] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id C723727BC061; Fri, 18 Jan 2013 04:23:21 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CA+hEJVXz61Z16v5scW=YnM_5f6MY==PBySor82hRFA+rbuDuZw@mail.gmail.com>
Date: Fri, 18 Jan 2013 04:23:21 -0800
Cc: Ian Hickson <ian@hixie.ch>, Julian Reschke <julian.reschke@greenbytes.de>, W3 HTML Public List <www-html@w3.org>, IETF HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1445F85-E1EA-4B2E-AE96-62361EFC025D@gbiv.com>
References: <DF0A84C4-AEAB-4716-B23F-FB3BA48BDE3C@gmail.com> <Pine.LNX.4.64.1301171948100.2101@ps20323.dreamhostps.com> <CA+hEJVXz61Z16v5scW=YnM_5f6MY==PBySor82hRFA+rbuDuZw@mail.gmail.com>
To: Nicholas Shanks <nickshanks@gmail.com>
X-Mailer: Apple Mail (2.1283)
Received-SPF: none client-ip=208.97.132.66; envelope-from=fielding@gbiv.com; helo=homiemail-a67.g.dreamhost.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-2.474, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001
X-W3C-Scan-Sig: maggie.w3.org 1TwAz1-00020u-JW f4be02d493630622445e937d5cd3ec5a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: The document's address
Archived-At: <http://www.w3.org/mid/E1445F85-E1EA-4B2E-AE96-62361EFC025D@gbiv.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16001
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>

On Jan 18, 2013, at 3:46 AM, Nicholas Shanks wrote:

> On 17 January 2013 19:49, Ian Hickson <ian@hixie.ch> wrote:
>> On Wed, 21 Nov 2012, Nicholas Shanks wrote:
>>> 
>>> The definition of the document's address:
>>> http://dev.w3.org/html5/spec/dom.html#the-document's-address
>>> doesn't mention if the Content-Location header should be taken into account.
>> 
>> My understanding is that Content-Location is essentially dead:
>> 
>>   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
> 
> That ticket says:
> 
> "2) HTTP's advice to set Content-Location when doing server-driven
> content negotiation results in links that are relative to a negotiated
> resource, rather than the desired (non-negotiated) URI."
> 
> 
> I find this is a real pain and wish I could turn it off in Apache. I
> only want Content-Location to be present when I intend it to be, e.g I
> want to do this:
> 
> POST /collection-uri
> { representation of new resource }
> 
> 201 Created
> Content-Location: /resource-uri
> { representation of created resource }
> 
> and have caches and the address in the browser's address bar use the
> given Content-Location for the representation returned, not use the
> request URI.

Which would be a security hole if /collection-uri and /resource-uri
are controlled by different owners.  In practice, there is no way
for clients to know the scope of resource ownership.

Search for "cache poisoning" for more explanation.

> But instead I have to do this:
> 
> POST /collection-uri
> { representation of new resource }
> 
> 303 Go Here
> Content-Location: /resource-uri
> 
> GET /resource-uri
> 
> 200 OK
> { representation of created resource }
> 
> 
> requiring an extra round-trip and losing the semantics of a 201
> response. If HTTP could be changed so that content negotiation MUST
> NOT cause C-L: header to be added, and HTTP software patched to obey
> this, then there may be scope in the future for requiring UAs to
> display the Content-Location rather than the request URI, once servers
> have had their software updated. HTTP 1.x may be a lost cause, but
> there is still time to fix it for 2.0

Not likely in either case,

....Roy