- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Sep 2014 14:46:47 +0300
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, sandro@w3.org
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. > >> 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 11:47:17 UTC