Re: HTTP Content-Location header usage

Mark Nottingham <mnot@mnot.net> Wed, 28 September 2016 06:15 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 DBDF112B391 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Sep 2016 23:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.237
X-Spam-Level:
X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfLkrRQchcZz for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Sep 2016 23:15:30 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B87312B337 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 27 Sep 2016 23:15:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bp85d-0006dX-3p for ietf-http-wg-dist@listhub.w3.org; Wed, 28 Sep 2016 06:11:33 +0000
Resent-Date: Wed, 28 Sep 2016 06:11:33 +0000
Resent-Message-Id: <E1bp85d-0006dX-3p@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1bp85R-0006Zi-5D for ietf-http-wg@listhub.w3.org; Wed, 28 Sep 2016 06:11:21 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by lisa.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1bp85P-0006r2-9F for ietf-http-wg@w3.org; Wed, 28 Sep 2016 06:11:20 +0000
Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C10A922E1F3; Wed, 28 Sep 2016 02:10:54 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAGnWK0SnbuXk69jaWm8PY88G7pyVx1zKkY9Och6SApeVJjhQBw@mail.gmail.com>
Date: Wed, 28 Sep 2016 16:10:51 +1000
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AAD31B4-0F30-46F3-AA19-AE136FD7066F@mnot.net>
References: <CAGnWK0SnbuXk69jaWm8PY88G7pyVx1zKkY9Och6SApeVJjhQBw@mail.gmail.com>
To: =?utf-8?B?0J3QuNC60LjRgtCwINCf0LjRgdC60YPQvdC+0LI=?= <n.piskunov91@gmail.com>
X-Mailer: Apple Mail (2.3226)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.6
X-W3C-Hub-Spam-Report: AWL=1.039, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bp85P-0006r2-9F 56e830d61c078e1fd5a25b4c31c59dba
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP Content-Location header usage
Archived-At: <http://www.w3.org/mid/8AAD31B4-0F30-46F3-AA19-AE136FD7066F@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32424
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 21 Sep. 2016, at 10:35 pm, Никита Пискунов <n.piskunov91@gmail.com> wrote:
> 
> Hello,
> i've already posted my comment about ambiguous Content-Location header usage description here as a GitHub Issue. And I've also decided to raise the discussion via email.
> 
> So, my question is:
> 
> The RFC 5789 discribes the apropriate usage of Content-Location header in PATCH:
> 
> A response to this method is only cacheable if it contains explicit freshness information (such as an Expires header or "Cache-Control: max-age" directive) as well as the Content-Location header matching the Request-URI, indicating that the PATCH response body is a resource representation.
> So, it means, that Content-Location header must appear only if the actual represantation is the part of response body for PATCH.

No. Content-Location can appear; it indicates a URL for the representation in the message. *If* it matches the request-target, you can deduce that it's a representation of what's currently at that resource (after the PATCH is applied). But if it doesn't match, it can still appear.

> Also the usage of Content-Location is mentioned in another RFC 7231:
> 
> For a state-changing request like PUT (Section 4.3.4) or POST (Section 4.3.3), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the need for a subsequent GET request.
> So, accordingly to this information in both RFCs, the apropriate usage of Content-Location with state-changing requests are following:
> Content-Location must appear in response only if response-body contains the new resourse representation.
> 
> But, there is also an example in RFC 5789:
> 
> Successful PATCH response to existing text file:
> 
> HTTP/1.1 204 No Content
> Content-Location: /file.txt
> ETag: "e0023aa4f"
> 
> The 204 response code is used because the response does not carry a message body (which a response with the 200 code would have). Note that other success codes could be used as well.
> 
> Furthermore, the ETag response header field contains the ETag for the entity created by applying the PATCH, available at http://www.example.com/file.txt, as indicated by the Content-Location response header field.
> How you can see, there is a Content-Location presented in response with 204 status code (No content). Ofcourse, this response doesn't contain any body as well as new resourse representation. This fact adds some ambiguity in Content-Location header description. What is the correct usage of this header?
> 

--
Mark Nottingham   https://www.mnot.net/