- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Mon, 25 Aug 2014 20:11:07 -0400
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>
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.
Received on Tuesday, 26 August 2014 00:11:12 UTC