- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Tue, 2 Sep 2014 11:00:09 -0400
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, sandro@w3.org
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? > 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.
Received on Tuesday, 2 September 2014 15:00:17 UTC