- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 04 Sep 2014 08:36:37 -0400
- To: Mark Nottingham <mnot@mnot.net>, Eric Prud'hommeaux <eric@w3.org>
- CC: HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>
On 09/04/2014 07:46 AM, Mark Nottingham wrote:
> On 2 Sep 2014, at 6:00 pm, Eric Prud'hommeaux <eric@w3.org> wrote:
>
>> Sorry for the delayed response; moving house. Will try to be more
>> attentive now.
>>
>> * Mark Nottingham <mnot@mnot.net> [2014-08-26 12:20+1000]
>>> Eric,
>>>
>>> We’re happy to discuss it here, but can’t commit to a schedule before that discussion has begun.
>>>
>>> For my part, I’m still not sure what the difference between the proposed status code is from 200 + Content-Location.
>> I think there are two ways this discussion could go:
>>
>> We could ask questions like "Is /Index?page=1 a representation of
>> /Index ?" and "What is the subject of the metadata in a 200+CL, the
>> effective request URI or the CL?" The end result of these is that we
>> evaluate the use cases for 303.
>>
>> Another is that we say 303's exist and people use them and want to
>> streamline their use. I believe that any approach to do so will find
>> some way to say that the metadata in the response is about the target
>> of the redirect. Is there a more graceful way to do that than 2NN?
> Eric,
>
> You haven’t answered the question; you’ve speculated on two different ways that the question might be answered.
>
> Choose.
>
Eric just meant there are multiple reasons for doing this, that is,
multiple correct answers. I think his phrasing was intended to let you
pick which one you wanted to dig into (and perhaps try to refute) first.
Personally, I think the first argument is stronger, so it would save
time to consider it first.
-- Sandro
>
>
>>> Cheers,
>>>
>>>
>>> On 26 Aug 2014, at 10:11 am, Eric Prud'hommeaux <eric@w3.org> wrote:
>>>
>>>> I understand people are busy, but is there a chance we can move forward
>>>> on this? The subject has been extensively discussed on
>>>> www-tag (as detailed below). The June I-D is at:
>>>> http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00
>>>>
>>>> Technical Summary:
>>>> [[
>>>> 2NN provides a shorcut the GET X->303 Location:Y, GET Y->200 pattern.
>>>> For responses where the server would have responded with a Location
>>>> header, it can instead respond with the payload of a notional GET on
>>>> that location. The notional GET has all of the headers of the original
>>>> request. This defines the behavior for conneg, Vary headers, caching,
>>>> etc.
>>>> ]]
>>>>
>>>> There's a fairly thorough summary in the TAG's draft review:
>>>> https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md
>>>> The issues in that document have been addressed in the I-D, but it
>>>> does contain motivation for 2NN (especially with respect to Server
>>>> Push).
>>>>
>>>> The urgency here is that the W3C Linked Data Platform (LDP) Working
>>>> Group, which first surfaced the need for this, will be ready to issue
>>>> its formal "Call for Implementations" in mid-September. At that
>>>> point, people outside the LDP Working Group will begin writing code
>>>> that uses this response code.
>>>>
>>>> I understand there may still be some concerns. In the next few weeks,
>>>> we'd like to try to address them or resolve that they are truly
>>>> insurmountable. Is that reasonable?
>>>>
>>>> I went throught the www-tag archives and added my own summary,
>>>> underneath, for each message:
>>>> -------------------------------------------------------------------------
>>>> A new HTTP response code say 209 Dec 19 Tim Berners-Lee
>>>> │ use case for a 209
>>>> ├─>Re: A new HTTP response code say 209 Dec 19 Daniel Appelquist
>>>> │ London f2f logistics
>>>> ├─>Re: A new HTTP response code say 209 Dec 19 Julian Reschke
>>>> │ │ 299 as placeholder
>>>> │ │ why not 303 or 202?
>>>> │ └─> Dec 20 Tim Berners-Lee
>>>> │ payload conflict of 303
>>>> │ 202 for asynchronous
>>>> │ 303 fine logically but requires round trip
>>>> ├─>Re: A new HTTP response code say 209 Dec 20 Mark Nottingham
>>>> │ │ use media type instead?
>>>> │ │ HTTPbis 8.2.2. Considerations for New Status Codes
>>>> │ └─> Jan 09 Henry Story
>>>> │ │ media types describe representation, not resource
>>>> │ ├─> Jan 09 Henry S. Thompson
>>>> │ │ │ define in terms of 303+200
>>>> │ │ ├─> Jan 09 Henry Story
>>>> │ │ │ │ +1 but propose 3xx instead of 2xx
>>>> │ │ │ └─> Jan 09 David Sheets
>>>> │ │ │ │ respond with message/http
>>>> │ │ │ ├─> Jan 09 David Booth
>>>> │ │ │ │ │ broaden 209 to cover 300, 301, 302 and 307
>>>> │ │ │ │ └─> Jan 09 David Booth
>>>> │ │ │ │ or 300, 301, 302 or 307 + multipart body
>>>> │ │ │ └─> Feb 13 Reto Gmür
>>>> │ │ │ confuses clients interpreting 2xx as 200
>>>> │ │ │ could work in 303
>>>> │ │ ├─>Fwd: A new HTTP response code say 209 Jan 09 Jonathan A Reese
>>>> │ │ │ no evidence that 200 has intended semantics in practice
>>>> │ │ └─> Jan 09 Julian Reschke
>>>> │ │ │ use 3xx code. 2xx response would apply to request-URI
>>>> │ │ └─> Jan 09 Henry S. Thompson
>>>> │ │ │ Content-location understood wrt conneg
>>>> │ │ └─> Jan 09 Julian Reschke
>>>> │ │ │ says there's a more specific URI
>>>> │ │ └─> Feb 10 Ashok Malhotra
>>>> │ │ │ Arwe: propose: 303 + Prefer: return=representation
>>>> │ │ └─> Feb 13 Yves Lafon
>>>> │ │ dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
>>>> │ └─> Jan 09 Julian Reschke
>>>> │ wording of 303
>>>> ├─>Re: A new HTTP response code say 209 Dec 19 Jonathan A Reese
>>>> │ note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
>>>> └─>draft of Feb 24 Eric Prud'hommeaux
>>>> │ draft <http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
>>>> ├─>Re: draft of 209 proposal Feb 24 David Booth
>>>> │ │ URL correction
>>>> │ └─> Feb 24 Eric Prud'hommeaux
>>>> │ │ ack
>>>> │ └─> Mar 17 Julian Reschke
>>>> │ │ Conflates "see elsewhere" with "too large", how can client know which applies
>>>> │ └─> Mar 17 Eric Prud'hommeaux
>>>> │ all that HTTP cares is that the client requested X and got something other than X
>>>> └─> Mar 07 Mark Nottingham
>>>> │ why is 209 better than 200 with Content-Location for e.g. POST->303 and GET->303?
>>>> │ partial feeds is addressed in RFC5005
>>>> │ how does HTTP software behave differently?
>>>> ├─> Mar 07 Julian Reschke
>>>> │ offer to help submit I-D
>>>> ├─> Mar 07 Eric Prud'hommeaux
>>>> │ │ GET->303 requires a round trip
>>>> │ │ RFC5005 re-uses URL for a page of resource. requires syndication format (Atom)
>>>> │ │ ack, same-origin constraint insufficient for shared caches
>>>> │ ├─> Mar 08 Julian Reschke
>>>> │ │ submit I-D via http://www.ietf.org/id-info/
>>>> │ ├─> Mar 08 Jeni Tennison
>>>> │ │ TAGs use of URLs http://www.w3.org/TR/urls-in-data/ includes 303s
>>>> │ └─> Mar 13 Mark Nottingham
>>>> │ │ not really a redirect so 200 with Content-Location should suffice
>>>> │ │ RFC5005 doesn't require URL re-use
>>>> │ │ why not embed paging info in served representations?
>>>> │ ├─> Mar 13 Jonathan A Rees
>>>> │ │ │ Content-Location is a representation of requested resource
>>>> │ │ ├─> Mar 16 Mark Nottingham
>>>> │ │ │ │ more details [on why Content-Location won't suffice]
>>>> │ │ │ └─> Mar 15 Jonathan A Rees
>>>> │ │ │ [discussion of non-information resources]
>>>> │ │ └─> Mar 17 Julian Reschke
>>>> │ │ │ is it OK that naive clients will treat 209 as 200?
>>>> │ │ └─> Mar 17 Eric Prud'hommeaux
>>>> │ │ small survey examining behavior of such clients
>>>> │ └─> Mar 15 Eric Prud'hommeaux
>>>> │ │ example differentiating page of resource from representation of resource
>>>> │ └─> Mar 16 Mark Nottingham
>>>> │ HTTP doesn't enable one representation to make an authoritative assertion about another
>>>> └─> Mar 07 Sandro Hawke
>>>> │ propose same-origin requirements for trusting 209 response
>>>> └─> Mar 07 Eric Prud'hommeaux
>>>> there are apparently different security reqs for client vs. proxies
>>>> proxies may not be content with same-origin, client proxies likely more liberal
>>>>
>>>> I believe Mark Nottingham remains concerned that 2NN's assertion about
>>>> the representation of the Location resource is counter to HTTP. The
>>>> Linked Data Platform's paging spec presumes that clients will take
>>>> advantage of the improved efficiency.
>>>> --
>>>> -ericP
>>>>
>>>>
>>>> * Julian Reschke <julian.reschke@gmx.de> [2014-06-30 19:40+0200]
>>>>> (FYI)
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: I-D Action: draft-prudhommeaux-http-status-2nn-00.txt
>>>>> Date: Mon, 30 Jun 2014 09:08:17 -0700
>>>>> From: internet-drafts@ietf.org
>>>>> Reply-To: internet-drafts@ietf.org
>>>>> To: i-d-announce@ietf.org
>>>>> X-ArchivedAt: http://www.w3.org/mid/53B1A11E.7070206@gmx.de
>>>>>
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>>
>>>>>
>>>>> Title : The Hypertext Transfer Protocol (HTTP)
>>>>> Status Code 2NN (Contents of Related)
>>>>> Author : Eric G. Prud'hommeaux
>>>>> Filename : draft-prudhommeaux-http-status-2nn-00.txt
>>>>> Pages : 9
>>>>> Date : 2014-06-30
>>>>>
>>>>> Abstract:
>>>>> This document specifies the additional HyperText Transfer Protocol
>>>>> (HTTP) Status Code 2NN (Contents of Related). It also specified a
>>>>> Prefer header value "contents-of-related" which clients can use to
>>>>> indicate that they can accept 2NN responses.
>>>>>
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-prudhommeaux-http-status-2nn/
>>>>>
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> I-D-Announce@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> -ericP
>>>>
>>>> office: +1.617.599.3509
>>>> mobile: +33.6.80.80.35.59
>>>>
>>>> (eric@w3.org)
>>>> Feel free to forward this message to any list for any purpose other than
>>>> email address distribution.
>>>>
>>>> There are subtle nuances encoded in font variation and clever layout
>>>> which can only be seen by printing this message on high-clay paper.
>>>>
>>> --
>>> Mark Nottingham http://www.mnot.net/
>>>
>>>
>>>
>> --
>> -ericP
>>
>> office: +1.617.599.3509
>> mobile: +33.6.80.80.35.59
>>
>> (eric@w3.org)
>> Feel free to forward this message to any list for any purpose other than
>> email address distribution.
>>
>> There are subtle nuances encoded in font variation and clever layout
>> which can only be seen by printing this message on high-clay paper.
> --
> Mark Nottingham http://www.mnot.net/
>
>
>
>
Received on Thursday, 4 September 2014 12:36:47 UTC