Re: 2NN Contents Of Related (303 Shortcut)

[Martin Thomson <[e-mail]>]

Perhaps events have overtaken this and the need can now be fulfilled by
server push instead.
On Aug 25, 2014 5:15 PM, "Eric Prud'hommeaux" <[e-mail]> 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 <[e-mail]> [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: [e-mail]
> > Reply-To: [e-mail]
> > To: [e-mail]
> > X-ArchivedAt: http://www.w3.org/mid/[e-mail]
> >
> >
> > 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
> > [e-mail]
> > 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: [phone]
>
> ([e-mail])
> 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.
>
>