Re: 2NN Contents Of Related (303 Shortcut)

* Martin Thomson <martin.thomson@gmail.com> [2014-08-25 19:12-0700]
> Perhaps events have overtaken this and the need can now be fulfilled by
> server push instead.

Jeni Tenison wrote some notes addressing that:
  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.
> >
> >

-- 
-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 13:21:43 UTC

Follow Lee on X/Twitter - Father, Husband, Serial builder creating AI, crypto, games & web tools. We are friends :) AI Will Come To Life!

Check out: eBank.nz (Art Generator) | Netwrck.com (AI Tools) | Text-Generator.io (AI API) | BitBank.nz (Crypto AI) | ReadingTime (Kids Reading) | RewordGame | BigMultiplayerChess | WebFiddle | How.nz | Helix AI Assistant