- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 26 Aug 2014 12:20:21 +1000
- To: Eric Prud'hommeaux <eric@w3.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>
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. 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: > 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.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: >> 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/
Received on Tuesday, 26 August 2014 02:20:52 UTC