Subject: Re: 2NN Contents Of Related (303 Shortcut)

From: Eric Prud'hommeaux <[email-masked]>
Date: Tue, 2 Sep 2014 09:21:33 -0400

* Martin Thomson <[email-masked]> [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:
  https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md#cant-you-just-wait-for-http2

In effect, if SPDY PUSH were widely available on servers and supported
conneg, we could use it with some implementatin cost (e.g. some API
for an apache module to initiate a push and client libraries to handle
asynchronous PUSH). At present, the deployment of 2NN is trivial with
either .asis or CGI scripts and there is pressure to resolve this
before a new version of HTTP is likely to be widely supported.

> On Aug 25, 2014 5:15 PM, "Eric Prud'hommeaux" <[email-masked]> 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 <[email-masked]> [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: [email-masked]
> > > Reply-To: [email-masked]
> > > To: [email-masked]
> > > X-ArchivedAt: http://www.w3.org/mid/[email-masked]
> > >
> > >
> > > 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
> > > [email-masked]
> > > 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
> >
> > ([email-masked])
> > 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

([email-masked])
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.

---

From: Eric Prud'hommeaux <[email-masked]>
Date: Tue, 2 Sep 2014 11:00:09 -0400

Sorry for the delayed response; moving house. Will try to be more
attentive now.

* Mark Nottingham <[email-masked]> [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 <[email-masked]> wrote:
> 
> > │   │               dangerous, changes 303, would need Vary: Prefer. 2xx more applicable
> > │                   note http://www.w3.org/2001/tag/doc/urls-in-data-2013-04-27/
> >  │                 draft <http://localhost/2014/02/2xx/draft-prudhommeaux-http-status-209>
> >  │     │           Conflates "see elsewhere" with "too large", how can client know which applies
> >  │                 all that HTTP cares is that the client requested X and got something other than X
> >    │               why is 209 better than 200 with Content-Location for e.g. POST->303 and GET->303?
> >    │ │             RFC5005 re-uses URL for a page of resource. requires syndication format (Atom)
> >    │ │             ack, same-origin constraint insufficient for shared caches
> >    │ │             TAGs use of URLs http://www.w3.org/TR/urls-in-data/ includes 303s
> >    │   │           not really a redirect so 200 with Content-Location should suffice
> >    │   │ │         Content-Location is a representation of requested resource
> >    │     │         example differentiating page of resource from representation of resource
> >    │               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
> >                    there are apparently different security reqs for client vs. proxies
> >                    proxies may not be content with same-origin, client proxies likely more liberal
> > 
> >> Please note that it may take a couple of minutes from the time of submission
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 

-- 
-ericP

office: +1.617.599.3509

([email-masked])

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Sep 2014 14:46:47 +0300

Eric,

You haven’t answered the question; you’ve speculated on two different ways that the question might be answered.

Choose.

---

From: Sandro Hawke <[email-masked]>
Date: Thu, 04 Sep 2014 08:36:37 -0400

> You haven’t answered the question; you’ve speculated on two different ways that the question might be answered.

Eric just meant there are multiple reasons for doing this, that is, 
multiple correct answers.  I think his phrasing was intended to let you 
pick which one you wanted to dig into (and perhaps try to refute) first.

Personally, I think the first argument is stronger, so it would save 
time to consider it first.

      -- Sandro

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Sep 2014 10:50:53 -0700

> evaluate the use cases for 303.

I think that saying we end up re-evaluating the need for 303 is
drawing a pretty long bow.

Why don't we talk instead about semantics.  What semantic distinction
are you looking to make?  There's a functional pattern you are looking
to enable (request this, get that instead, don't pay extra round
trips), but that pattern is supported by 200+CL.

---

From: Sandro Hawke <[email-masked]>
Date: Thu, 04 Sep 2014 18:02:53 -0400

> trips), but that pattern is supported by 200+CL.

It's a good question, and I'm not sure we have a great answer. Mostly, 
we want it to be possible for there to be semantic distinctions.   We're 
building infrastructure, not applications, so the distinctions are 
likely to be made at other layers.

Some possible distinctions that come to mind:

- search engines / indexing services -- these systems index which URLs 
provide content containing particular data items.   These systems are 
indexed by the URL; should they index the request URL or the CL?

- endorsement -- what we now see in social systems as Like/+1/star -- 
where the user sees something and gives it some kind of mark of 
approval.  Is that mark on just the first page of items, or the whole 
set?    Which URL should be considered endoresed?  It's possible the 
user will be frustrated, or worse, if they meant to mark one and the 
other was considered marked.

- link rel=alternate -- is that an alternate for this page or the whole 
thing?   Some alternates might be paged differently, so maybe it doesn't 
make sense for the page.

- link rel=copyright -- if the different items have different copyright, 
there might be multiple of these links to cover them all, and it will be 
different depending whether this is talking about the paged resource or 
just a page

- link rel=next/prev -- at first glance these obviously are about the CL 
not the requested resources, but what if the requested resource were 
itself in some kind of sequence?    Or what if the redirect were for 
some reason other than paging?

Again, I'm not claiming any of these are rock solid -- they're not 
applications I'm building right now -- we just think it's important that 
it remain possible to make these distinctions, and we don't see how 
200+CL does that.

      -- Sandro

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 4 Sep 2014 18:14:04 -0700

On Sep 4, 2014, at 3:02 PM, Sandro Hawke wrote:

> It's a good question, and I'm not sure we have a great answer. Mostly, we want it to be possible for there to be semantic distinctions.   We're building infrastructure, not applications, so the distinctions are likely to be made at other layers.

Given resources A and B,

  GET A -> 200 OK, CL: B
    implies that the payload is both a representation of A and of B
    (assuming the origin server is authoritative for both).

  GET A -> 303 See Other, Location: B
    implies that we don't have a representation of A, but B is interesting
    too so you might want to go over and get that if you haven't already.

  GET A -> 2NN Related, CL: B
    implies that we don't have a representation of A, but we know what you
    really wanted (better than you) so here is a representation of B.

Now, here's the problem:

"It's a round trip short cut!"  No, because it won't be cached.
303 round trips to the same server are almost entirely free in HTTP/1.1
because of persistent connections, so what you are really short-cutting
here is the chance for the user's cache to discover it already has a
representation of that other resource they didn't actually request and
might not even be interested in retrieving.

"Oh, but we know the user always wants that other resource because this
is a semantic web system!"  Then do yourself a favor and use templated
assertions to define links between those semanticky resources and the
descriptions the user really wanted in the first place, and just skip the
first request entirely.

   urn:world:{stuff} -> describedBy ("http://encyclopedia/query?{stuff}")

"Oh, but this isn't *just* a semantic web system -- we expect this to be
implemented by the entire Web!"  Well, then you don't know that the user
really wants to get a 2NN instead of a 303, and thus you are favoring
your own club of implementations over the general performance value
(and benefit to everyone on the Internet) of reusing cached representations.
Maybe that's when Prefer should be used instead.

> - search engines / indexing services -- these systems index which URLs provide content containing particular data items.   These systems are indexed by the URL; should they index the request URL or the CL?

I doubt that search engines index content of arbitrary status codes.
They do index the destinations of redirects, and they typically associate
aliased content with the most-linked URL.  2NN doesn't help at all.

> - endorsement -- what we now see in social systems as Like/+1/star -- where the user sees something and gives it some kind of mark of approval.  Is that mark on just the first page of items, or the whole set?    Which URL should be considered endoresed?  It's possible the user will be frustrated, or worse, if they meant to mark one and the other was considered marked.

2NN is not going to help you there.  You can't tell if they like a picture,
the person in the picture, the dog the person is holding in the picture,
or the sweater on the dog the person is holding in the picture.  The user
doesn't care either way -- they just want the owner to like them back.
The only ones who really care are the advertisers trying to figure out
which of those things the user might actually be interested in buying.

> - link rel=alternate -- is that an alternate for this page or the whole thing?   Some alternates might be paged differently, so maybe it doesn't make sense for the page.

Link relations are supposed to define what the relation applies to.
The response isn't going to make any difference.

> - link rel=copyright -- if the different items have different copyright, there might be multiple of these links to cover them all, and it will be different depending whether this is talking about the paged resource or just a page

Copyright links point to a description of the copyright for an expression
(the selected representation), but that description might encompass an
entire site of resources (e.g., it might be a database of copyright info).

> - link rel=next/prev -- at first glance these obviously are about the CL not the requested resources, but what if the requested resource were itself in some kind of sequence?    Or what if the redirect were for some reason other than paging?

They are defined as navigation links.  What does paging have to do with
any of this?  Whether "/Index?page=1" and "/Index" are the same or
(more likely) different resources is not going to be discoverable by
one look at their representations.  The response will be 200, regardless.

I have no doubt that we'll end up with a 2NN code anyway, because it is
easier to mint new codes than to explain why servers shouldn't use them.

....Roy

---

From: Sandro Hawke <[email-masked]>
Date: Thu, 04 Sep 2014 23:18:24 -0400

Thanks for the thorough response, Roy.   Details inline.

>      (assuming the origin server is authoritative for both).

Assuming you're right about this, and I agree you are, isn't that 
sufficient to answer Mark Nottingham's question of why not use 200+CL?   
In our use cases, the payload is not a representation of A.

>      too so you might want to go over and get that if you haven't already.

Right.

>    GET A -> 2NN Related, CL: B

Minor detail: in the I-D it's the Location header, not the 
Content-Location header.  This is to allow the Content-Location header 
to still be used with its normal Con-Neg purpose, as shown in the 
example in the draft.

See: http://tools.ietf.org/html/draft-prudhommeaux-http-status-2nn-00

>      really wanted (better than you) so here is a representation of B.

If I understand right, your "better than you" comment is about how there 
might already be a cache of B, and with 2NN that cached copy wont be 
used.  I agree that's a weakness in this proposal, although in all the 
scenarios I've seen discussed, it's unlikely B would be cached unless 
the 2NN response to A also was, so this weakness wouldn't be observed in 
practice.

> "It's a round trip short cut!"  No, because it won't be cached.

As above, in the scenarios we're looking at, it's unlikely B will be 
cached unless the 2NN response for A is also.

> because of persistent connections,

Free of connection setup overhead, but they still cost a second 
round-trip delay.

In LDP applications, these calls are more like RPC than like displaying 
a web-page, so milliseconds might possibly count more than they do in 
more common existing applications.

>   so what you are really short-cutting

The actual driving force behind this I-D is not about using 303s to deal 
with httpRange-14, it's to deal with paging.  That is, the client does a 
GET on A, including these request headers:

    Prefer: contents-of-related
    Prefer: return=representation; max-triple-count="100"

and now the server can directly provide the first hundred triples, via a 
representation of B, which is that the first "page" of A.

So templates wont help with that.

As an aside, is there a standard way to publish the kind of template 
assertion you provide above?   That would be useful for other things, 
indeed.

> really wants to get a 2NN instead of a 303,

We know the client wants a 2NN instead of a 303 because of the "Prefer: 
contents-of-related" headers.  Without that, or some other indication 
not currently standardized, 2NN wont be sent.

> and thus you are favoring

Existing search engines wont get a 2NN since they wont be including that 
prefer header.   New data search engines will be able to use it if they 
want.

> aliased content with the most-linked URL.  2NN doesn't help at all.

Again, the only point of 2NN is to help with the round-trip time. In the 
scenarios we're looking at, where there are many requests back to back 
over the same HTTP connection, the second round-trip can cut performance 
in half.

I'm going to skip the point-by-point on the following bits for now, 
unless you think they're still relevant given what I've said above.   
They were aimed at answering why 200+CL wasn't a solution.

> easier to mint new codes than to explain why servers shouldn't use them.

I hope I speak for the entire LDP Working Group when I say we'd be 
thrilled to drop this proposal if we saw a viable alternative using 
existing standards.

          -- Sandro

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Sep 2014 08:18:55 +0200

On 2014-09-05 05:18, Sandro Hawke wrote:
> ...
> ...

I'll mention again that it continues to confuse me that you're trying to 
address paging and "see other" with the same mechanism.

WRT paging: why don't you use a custom range 
(<http://greenbytes.de/tech/webdav/rfc7233.html#range.units.other>) such 
as in:

   Range: triples=100

?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Sep 2014 09:47:53 +0200

> the 2NN response to A also was, so this weakness wouldn't be observed in

Why wouldn't the response to the redirect GET (303 -> 200) not be cached?

> more common existing applications.

It that's the problem, have you considered to tweak 303 to actually 
return the representation of the "other" resource (using a new Prefer 
option?)?

GET / HTTP/1.1

HTTP/1.1 303 SEE OTHER
Location: /other
Preference-Applied: contents-of-related
...

(representation of /other)

?

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Fri, 5 Sep 2014 05:51:59 -0400 (EDT)

On Fri, 5 Sep 2014, Julian Reschke wrote:

> It that's the problem, have you considered to tweak 303 to actually return 
> the representation of the "other" resource (using a new Prefer option?)?
>
> GET / HTTP/1.1

From 7231:
<<
    Except for responses to a HEAD request, the representation of a 303
    response ought to contain a short hypertext note with a hyperlink to
    the same URI reference provided in the Location header field.
So tweaking 303 to return the content of Location: would be weird, even 
with the introduction of a new conneg header.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Yves Lafon <[email-masked]>
Date: Fri, 5 Sep 2014 05:53:49 -0400 (EDT)

On Fri, 5 Sep 2014, Julian Reschke wrote:

> (<http://greenbytes.de/tech/webdav/rfc7233.html#range.units.other>) such as 
> in:
>
>  Range: triples=100

If it is triggered by the client, then yes, it might be possible to use a 
custom range. However if the server decides to do paging for whatever 
reason, then it can't be used, and another mechanism is needed.

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Sep 2014 12:01:43 +0200

> with the introduction of a new conneg header.

I believe you're reading too much into the "ought to".

If the client clearly says "give me the representation of the 'other' 
resource", then the server ought to be able to do that. (pun intended)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Sep 2014 12:03:37 +0200

On 2014-09-05 11:53, Yves Lafon wrote:
>> (<http://greenbytes.de/tech/webdav/rfc7233.html#range.units.other>)
>> such as in:
>>
>>  Range: triples=100
>
> If it is triggered by the client, then yes, it might be possible to use
> a custom range. However if the server decides to do paging for whatever

But we *are* talking about "special" clients, right? Otherwise they 
wouldn't understand 2NN anyway.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Sep 2014 13:35:55 +0300

Right.

Also — Content-Location is *not* a flag that conneg has happened; that’s only a use case for it.

One important point that I don’t see being addressed here is that resource A is *claiming* that it’s presenting a representation of resource B — it isn’t authoritative for that resource (even if they’re on the same server). That’s an important distinction, and it’s precisely the one made by Content-Location.

Cheers,

On 5 Sep 2014, at 1:01 pm, Julian Reschke <[email-masked]> wrote:

> If the client clearly says "give me the representation of the 'other' resource", then the server ought to be able to do that. (pun intended)
> 
> Best regards, Julian
>

---

From: Sandro Hawke <[email-masked]>
Date: Fri, 05 Sep 2014 07:33:08 -0400

> Right.

Am I reading this correctly, that you and Julian think it would be 
better to use 303 + "Preference-Applied: contents-of-related" + the 
actual representation of B being returned, instead  of a new response 
code?     Procedurally, is that any easier to standardize?

In that case, would it make sense to generalize the preference to not 
just be for 303, but for all redirects?     Maybe "Prefer: 
send-content-and-headers-for-redirection-location" or "Prefer: 
server-follow-redirection" which could also be used with 301 or 307.

> Also — Content-Location is *not* a flag that conneg has happened; that’s only a use case for it.

I don't think we're suggesting it is, just that it's nice to keep it 
available for telling the client a URI for the content.

> One important point that I don’t see being addressed here is that resource A is *claiming* that it’s presenting a representation of resource B — it isn’t authoritative for that resource (even if th…

I hesitate to say anything on this, since I'm aware I've missed some of 
the discussion this key point.   I expect the thinking is that since the 
client is asking A, and trusting A to give it content, and A is 
providing content, it's not unreasonable to also trust A to say "I got 
this content from B".  It's then up to the client to decide how 
seriously to take the claim that it came from B.   The I-D is clear that 
folks are not to cache it as if it came from B (unless they have other 
justification).

      -- Sandro

---

From: Eric Prud'hommeaux <[email-masked]>
Date: Fri, 5 Sep 2014 09:01:39 -0400

* Sandro Hawke <[email-masked]> [2014-09-05 07:33-0400]
> actual representation of B being returned, instead  of a new
> response code?     Procedurally, is that any easier to standardize?
> 
> In that case, would it make sense to generalize the preference to
> not just be for 303, but for all redirects?     Maybe "Prefer:

We arrived at 2NN thinking that we couldn't change the behavior of
existing response codes. If that was a false assumption, I'd be happy
to take an alternate tack.

> available for telling the client a URI for the content.

The first example in the draft includes the conventional use for C-L.

The 303,200 interaction:
   GET /bigDoc, Accept: text/turtle -> 303, Location: http://bigco-static.example/p1
   GET /p1, Accept: text/turtle -> 200, Content-Location: http://bigco-static.example/p1.ttl
gets shortened to a single 2NN:
   GET /bigDoc, Accept: text/turtle -> 2NN, Location: http://bigco-static.example/p1, Content-Location: http://bigco-static.example/p1.ttl

http://datatracker.ietf.org/doc/draft-prudhommeaux-http-status-2nn/?include_text=1

> I hesitate to say anything on this, since I'm aware I've missed some
> of the discussion this key point.   I expect the thinking is that
> since the client is asking A, and trusting A to give it content, and
> A is providing content, it's not unreasonable to also trust A to say
> "I got this content from B".  It's then up to the client to decide
> how seriously to take the claim that it came from B.   The I-D is
> clear that folks are not to cache it as if it came from B (unless
> they have other justification).

Our use cases will involve high-volume interactions with a smallish
number of clients so user interface or configuration is a small price
to pay to reduce the latency of another round trip. The rules for
caching 2NN were copied from those for C-L.

-- 
-ericP

office: +1.617.599.3509

([email-masked])

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 5 Sep 2014 10:54:30 -0700

On Sep 4, 2014, at 8:18 PM, Sandro Hawke wrote:

> Assuming you're right about this, and I agree you are, isn't that sufficient to answer Mark Nottingham's question of why not use 200+CL?   In our use cases, the payload is not a representation of A.

Yes, they have distinct meanings.  That doesn't mean the distinction is
useful, but it is the answer to his question.

> Minor detail: in the I-D it's the Location header, not the Content-Location header.  This is to allow the Content-Location header to still be used with its normal Con-Neg purpose, as shown in the example in the draft.
> 

The I-D is wrong.  Please fix it.  CL is a link assertion that isn't so
much about conneg, but rather that conneg is one way to cause that
assertion to exist.  2NN would be another such way. They cannot conflict.

> If I understand right, your "better than you" comment is about how there might already be a cache of B, and with 2NN that cached copy wont be used.  I agree that's a weakness in this proposal, although in all the scenarios I've seen discussed, it's unlikely B would be cached unless the 2NN response to A also was, so this weakness wouldn't be observed in practice.

2NN responses cannot be cached by existing caches.  303 responses can, as
can the 200 responses after the redirection.  That's why we redirect (well,
that, and the fact that the destination might be in a different administrative
domain with its own authority and potential access controls).

> As above, in the scenarios we're looking at, it's unlikely B will be cached unless the 2NN response for A is also.

2NN responses will not be cached because HTTP forbids caching of unknown
status codes.  It might be cached by the special-purpose tool's cache,
but that is only one of the potential opportunities to cache.  Both the
2NN and the redirected 200 response (via 303) are lost to intermediate
caching and the resource itself has to be marked as Vary: Prefer.

Performance has to be evaluated from the perspective of systems design,
not individual requests.

> Free of connection setup overhead, but they still cost a second round-trip delay.
> 
> In LDP applications, these calls are more like RPC than like displaying a web-page, so milliseconds might possibly count more than they do in more common existing applications.

No, they don't.  A web page is far more latency sensitive than any LDP
application ever deployed that makes HTTP requests, and yet a typical
web page consists of dozens of round trips to multiple servers.  The practical
impact of a single round trip per extremely rare 303 response is far less
than the impact of adding 40 or so bytes to the critical path of every
request in the form of Prefer header fields.  If the LDP knows it is going
to get a lot of 2NN responses (i.e., it is not sending requests to the open
Web), then it shouldn't be sending those requests in the first place.

> The actual driving force behind this I-D is not about using 303s to deal with httpRange-14, it's to deal with paging.  That is, the client does a GET on A, including these request headers:
> 
> and now the server can directly provide the first hundred triples, via a representation of B, which is that the first "page" of A.

The first hundred triples is a representation of resource A.
There is no requirement, anywhere, that representations be complete.
Prefer in this case is just another form of content negotiation and
the response is 200.  Responding 303 in this case would be wrong,
as would 2NN.

> So templates wont help with that.

It doesn't seem to be a relevant question.  If the client knows enough to
send Prefer, then it can also know what CL means.  2NN should not be sent
in this case.

> As an aside, is there a standard way to publish the kind of template assertion you provide above?   That would be useful for other things, indeed.

It is just a translation table with two URI Templates, like a combo of

   http://www.w3.org/People/Fielding/draft-ietf-uri-roy-urn-urc-00.txt

and

   http://tools.ietf.org/html/rfc6570

> We know the client wants a 2NN instead of a 303 because of the "Prefer: contents-of-related" headers.  Without that, or some other indication not currently standardized, 2NN wont be sent.

Okay, then include that in your costs.

> Existing search engines wont get a 2NN since they wont be including that prefer header.   New data search engines will be able to use it if they want.
> 
> Again, the only point of 2NN is to help with the round-trip time. In the scenarios we're looking at, where there are many requests back to back over the same HTTP connection, the second round-trip can cut performance in half.

If the requests are always resulting in 303s, then you are requesting the
wrong things.  This is just like when XML parser developers complained that
the W3C site was slowing down their document parsing because it couldn't
handle dynamic requests for static DTDs.  The right solution was to fix the
tools.

....Roy

---

From: Eric Prud'hommeaux <[email-masked]>
Date: Fri, 5 Sep 2014 16:00:23 -0400

* Roy T. Fielding <[email-masked]> [2014-09-05 10:54-0700]
> assertion to exist.  2NN would be another such way. They cannot conflict.

In my reply to Sandro, I attempted to demonstrate how they are both
used in a complementary way, Location identifying the target of a 303
redirect and C-L identifying the negotiated representation of that
Location. I understand that there are other variants which may affect
the C-L, but I don't see why it's wrong that 2NN preserves the meaning
of both of those headers.

> Performance has to be evaluated from the perspective of systems design,

I agree that both have to be taken into account. I suspect that this
situation is self-correcting. If 2NN represents a very small fraction
of web traffic, then there's little impact and little incentive for
proxies to become 2NN-aware. The cost of using 2NN is evaluated by the
clients and they can send the Prefer or not.

If deployment takes the web by storm (as I'm sure we're all
anticipating), there will be incentive for people to program proxies
which will cache 2NN. They may even want the proxy to send an out-of-
band GET to verify the final resource, which I admit is not fabulous
traffic-wise, but still appears to be an optimum for responsiveness on
the initial request and cache hits for the subsequent requests.

> web page consists of dozens of round trips to multiple servers.

A huge amount of resource has gone into progressive rendering to deal
with this sort of latency.

>                                                                  The practical

I'm not sure I understand the last argument (which seems most germane
to our use cases). If LDP clients accout for a small fraction of web
traffic, but most of their traffic involves 303s, the incentive to
optimize their traffic offsets the impact their traffic will have on
conventional proxies. (What's the deployment of caches today? I
imagine we could put numbers to this argument.)

> the response is 200.  Responding 303 in this case would be wrong,

Is the second hundred triples also a representation of resource A?
Are they all resource A?

Perhaps your argument is that "Prefer" is the wrong header to signal
the client's ability to handle 2NN.

> Okay, then include that in your costs.

Fair enough, but 28 bytes is a small impact compared to a strictly
sequential extra round trip.

> handle dynamic requests for static DTDs.  The right solution was to fix the

Fair enough, but we need a fix. I'm not sure if you propose 200+C-L
(you appear to argue against it above) or that we discount use cases
like the Linked Data Platform which request resources which frequently
grow to be impractical to send in a single gulp.

-- 
-ericP

office: +1.617.599.3509

([email-masked])

---

From: Sandro Hawke <[email-masked]>
Date: Sun, 07 Sep 2014 10:43:33 -0400

> the response is 200.  Responding 303 in this case would be wrong,

This is a crucial point.    If even responding 303 is wrong, we have a 
bigger problem.

It sounds to me like you're saying that a chapter of a book is the same 
thing as the entire book.

Let's say we have an online textbook available at:

    http://example.org/WebDesign

and each of its 40 chapters is available as a separate web page, with 
chapter number CC being available at

    http://example.org/WebDesign?chapter={CC}

Now imagine a client does GET http://example.org/WebDesign, with a 
prefer header saying it's fine to just send the first chapter if the 
book is too big.

I think you're saying it would be fine for the server to respond 200 OK, 
Content-Location: http://example.org/WebDesign?chapter=1, and give the 
content of that first chapter.

To my understanding, that's wrong, because it violates the semantics of 
200 OK and Content-Location.  Specifically, since a book is not the same 
thing as its first chapter, http://example.org/WebDesign and 
http://example.org/WebDesign?chapter=1 are distinct resources. If they 
are distinct we can't use 200 OK+CL to respond to one with the other.

I think I hear you saying that resources being distinct doesn't matter, 
that the notion of "representation" is much fuzzier than that.  I think 
you're saying that even though a chapter of a book and a book are 
different, it's fine to response 200 OK and give the text of the chapter 
as a representation of the book (assuming there was some negotiation 
licensing such behavior).

If the HTTP WG really has consensus on that idea, I guess I can live 
with it, even though it's counterintuitive to me.

But how far does this go?    When is 200+CL not okay?    Could the first 
sentence of the book be a representation of it?   How about the the 
first letter?   How about the 10th letter?    How about the 13th, 7th, 
and 22nd letters, in that order?    How about the first word of a 
different book?   How about the first sentence of a different book?   
How about the entire contents of a different book?    I don't see how 
you can draw a line here, with this way of thinking about it.

To me, and the LDP WG, it's made a lot more sense to think of a chapter 
as simply being a different resource than the book, so if the server's 
going to give back a representation of the chapter, it can't use 200 OK.

          -- Sandro

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 7 Sep 2014 10:30:02 -0700

> On Sep 7, 2014, at 7:43 AM, Sandro Hawke <[email-masked]> wrote:
> 
> This is a crucial point.    If even responding 303 is wrong, we have a bigger problem.
> 
> It sounds to me like you're saying that a chapter of a book is the same thing as the entire book.   

No, you are assuming it is a book.

> and each of its 40 chapters is available as a separate web page, with chapter number CC being available at
> Now imagine a client does GET http://example.org/WebDesign, with a prefer header saying it's fine to just send the first chapter if the book is too big.

Then that resource is more than just a book. It provides views of the resource state, which is no more or less than what content negotiation provides in HTTP.

> I think you're saying it would be fine for the server to respond 200 OK, Content-Location: http://example.org/WebDesign?chapter=1, and give the content of that first chapter.

The server can respond however they like. It is only the consistency of those responses that defines what the resource might be, to any extent that matters.

> To my understanding, that's wrong, because it violates the semantics of 200 OK and Content-Location.  Specifically, since a book is not the same thing as its first chapter, http://example.org/WebDesign and http://example.org/WebDesign?chapter=1 are distinct resources.  If they are distinct we can't use 200 OK+CL to respond to one with the other.

But the first URI is not a book. You cannot define it as one thing and then say its behavior doesn't fit that definition. It is not that thing.

> I think I hear you saying that resources being distinct doesn't matter, that the notion of "representation" is much fuzzier than that.  I think you're saying that even though a chapter of a book and a book are different, it's fine to response 200 OK and give the text of the chapter as a representation of the book (assuming there was some negotiation licensing such behavior).

No, I am saying that the responses define the resource, not the other way around. If you have distinct URIs with decidedly different behavior, like your chapters, then they are of course distinct resources. So is the resource that always responds with a complete book. It is defined by what it does.

A successful response to GET is a representation of the target resource. Range, for example, does not alter the representation; it simply provides a range of that representation in the payload of a 206. Conneg doesn't alter the representation either. It merely selects one of the available representations.

So, if 2NN is a success to GET, it has to convey a selected representation of that resource.  Not some other resource, though it is fine for a single representation to represent multiple resources. 3xx, in contrast, says the request was not successful but this other thing might be just as good.

There is nothing wrong with having a representation of a resource that is a paged view. The only need is that something in the representation data or metadata indicates that view, preferably with prev, this, and next links. CL is a "this" link. The resource is then partially defined by the fact that it offers views of the overall state. All 200 responses. No big deal.

> If the HTTP WG really has consensus on that idea, I guess I can live with it, even though it's counterintuitive to me.
> 
> But how far does this go?    When is 200+CL not okay?    Could the first sentence of the book be a representation of it?   How about the the first letter?   How about the 10th letter?    How about the 13th, 7th, and 22nd letters, in that order?    How about the first word of a different book?   How about the first sentence of a different book?   How about the entire contents of a different book?    I don't see how you can draw a line here, with this way of thinking about it.

There are no lines. There is no need for any.

> To me, and the LDP WG, it's made a lot more sense to think of a chapter as simply being a different resource than the book, so if the server's going to give back a representation of the chapter, it can't use 200 OK.

The server is in control of what it's resources mean. If a resource is not limited to being an entire book, then it isn't an entire book. There's no reason to pretend otherwise.

....Roy.

---

From: Sandro Hawke <[email-masked]>
Date: Sun, 07 Sep 2014 15:59:14 -0400

On 09/07/2014 01:30 PM, Roy T. Fielding wrote:
> On Sep 7, 2014, at 7:43 AM, Sandro Hawke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Then that resource is more than just a book. It provides views of the 
> resource state, which is no more or less than what content negotiation 
> provides in HTTP.
>
>
>> I think you're saying it would be fine for the server to respond 200 
>> OK, Content-Location: http://example.org/WebDesign?chapter=1, and 
>> give the content of that first chapter.
>
> The server can respond however they like. It is only the consistency 
> of those responses that defines what the resource might be, to any 
> extent that matters.
>

Okay, thanks for the explanation.

I don't see this leading to 303 being wrong, though.   Isn't it up to us 
(the group defining how LDP servers behave when answering for LDP 
resources) to define whether LDP resources can or cannot be represented 
by subset pages of it?

So far, we've said the representations of these resources (technically 
LDP RDF Sources) are RDF serializations of all the triples which 
comprise the state of the resource.   (There's one exception, where 
certain redundant triples can be omitted when the client sends the 
appropriate Prefer header.)

I hear you saying we wouldn't be violating any HTTP specs by saying, 
"Actually the representation could be subsets of that graph state."

But I don't see anything mandating that approach either.   My 
understanding is RDF software is pretty much always written with the 
assumption that the representation will include a serialization of every 
triple.   I think we'd prefer to align this work with that community 
practice.

>> To my understanding, that's wrong, because it violates the semantics 
>> of 200 OK and Content-Location.  Specifically, since a book is not 
>> the same thing as its first chapter, http://example.org/WebDesign and 
>> http://example.org/WebDesign?chapter=1 are distinct resources.  If 
>> they are distinct we can't use 200 OK+CL to respond to one with the 
>> other.
>
> But the first URI is not a book. You cannot define it as one thing and 
> then say its behavior doesn't fit that definition. It is not that thing.
>
>> I think I hear you saying that resources being distinct doesn't 
>> matter, that the notion of "representation" is much fuzzier than 
>> that.  I think you're saying that even though a chapter of a book and 
>> a book are different, it's fine to response 200 OK and give the text 
>> of the chapter as a representation of the book (assuming there was 
>> some negotiation licensing such behavior).
>
> No, I am saying that the responses define the resource, not the other 
> way around. If you have distinct URIs with decidedly different 
> behavior, like your chapters, then they are of course distinct 
> resources. So is the resource that always responds with a complete 
> book. It is defined by what it does.
>

Right, that's our model.   We have resource like books, and we have 
resources like chapters.   We think of them as distinct types of things, 
and define specific behaviors for each of them, include headers they 
provide to indicate what they are, and restrictions on how they respond 
to GET, POST, etc.

We expect that sometimes some "books" will get to be quite large (many 
GB).  So we want the servers to be able to respond to a naive GET on a 
"book" with a 303 to the first chapter.   If it tried to stream the 
whole thing, we expect we'd have real problems.   We encourage clients 
to say what max response size they want; servers should use that 
information and send the biggest size they and the client are okay with.

Do you see any problem with that use of 303?    I hope not.

The one problem we see is that it's an extra roundtrip.    One could 
argue so what, but our application developers seem to care, so thus the 
idea of a 2NN which has the semantics of bundling the 303  and a 
subsequent 200 into one round-trip.

As you've pointed out, this wont be able to use existing caches, and has 
some other caching weaknesses.

> A successful response to GET is a representation of the target 
> resource. Range, for example, does not alter the representation; it 
> simply provides a range of that representation in the payload of a 
> 206. Conneg doesn't alter the representation either. It merely selects 
> one of the available representations.
>
> So, if 2NN is a success to GET, it has to convey a selected 
> representation of that resource.

Really?    Certainly for 200, but why for 2NN? 
http://tools.ietf.org/html/rfc7231#page-51 section 6.3 doesn't say every 
2xx has to be like that.

>  Not some other resource, though it is fine for a single 
> representation to represent multiple resources. 3xx, in contrast, says 
> the request was not successful but this other thing might be just as good.
>
> There is nothing wrong with having a representation of a resource that 
> is a paged view. The only need is that something in the representation 
> data or metadata indicates that view, preferably with prev, this, and 
> next links. CL is a "this" link. The resource is then partially 
> defined by the fact that it offers views of the overall state. All 200 
> responses. No big deal.
>
>> first letter?   How about the 10th letter?    How about the 13th, 
>> 7th, and 22nd letters, in that order?    How about the first word of 
>> a different book?   How about the first sentence of a different book? 
>>   How about the entire contents of a different book?    I don't see 
>> how you can draw a line here, with this way of thinking about it.
>
>> To me, and the LDP WG, it's made a lot more sense to think of a 
>> chapter as simply being a different resource than the book, so if the 
>> server's going to give back a representation of the chapter, it can't 
>> use 200 OK.
>
> The server is in control of what it's resources mean. If a resource is 
> not limited to being an entire book, then it isn't an entire book. 
> There's no reason to pretend otherwise.

LDP wants certain machine interoperability characteristics which are not 
in standard HTTP, so it's defining a more restrictive class of 
resources, which are less free to behave as they want.

          -- Sandro

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 08 Sep 2014 14:48:36 +1200

On 8/09/2014 7:59 a.m., Sandro Hawke wrote:
>>>>>> The actual driving force behind this I-D is not about
>>>>>> using 303s
>>>>> to deal with httpRange-14, it's to deal with paging.  That
>>>>> is, the client does a GET on A, including these request
>>>>> headers:
>>>>>> 
>>>>>> Prefer: contents-of-related Prefer:
>>>>>> return=representation; max-triple-count="100"
>>>>>> 
>>>>>> and now the server can directly provide the first hundred
>>>>>> triples,
>>>>> via a representation of B, which is that the first "page"
>>>>> of A.
>>>> There is no requirement, anywhere, that representations be
>>>> complete. Prefer in this case is just another form of content
>>>> negotiation and the response is 200.  Responding 303 in this
>>>> case would be wrong, as would 2NN.
>>>> 
>>> 
>>> and each of its 40 chapters is available as a separate web
>>> page, with chapter number CC being available at
>>> 
>>> Now imagine a client does GET http://example.org/WebDesign,
>>> with a prefer header saying it's fine to just send the first
>>> chapter if the book is too big.
>> 
>> Then that resource is more than just a book. It provides views of
>> the resource state, which is no more or less than what content
>> negotiation provides in HTTP.
>> 
>> 
>>> I think you're saying it would be fine for the server to
>>> respond 200 OK, Content-Location:
>>> http://example.org/WebDesign?chapter=1, and give the content of
>>> that first chapter.
>> 
>> The server can respond however they like. It is only the
>> consistency of those responses that defines what the resource
>> might be, to any extent that matters.
>> 
> 
> I don't see this leading to 303 being wrong, though.   Isn't it up
> to us (the group defining how LDP servers behave when answering for
> LDP resources) to define whether LDP resources can or cannot be
> represented by subset pages of it?
> 
> So far, we've said the representations of these resources
> (technically LDP RDF Sources) are RDF serializations of all the
> triples which comprise the state of the resource.   (There's one
> exception, where certain redundant triples can be omitted when the
> client sends the appropriate Prefer header.)
> 
> I hear you saying we wouldn't be violating any HTTP specs by
> saying, "Actually the representation could be subsets of that graph
> state."
> 
> understanding is RDF software is pretty much always written with
> the assumption that the representation will include a serialization
> of every triple.   I think we'd prefer to align this work with that
> community practice.
> 
>>> To my understanding, that's wrong, because it violates the
>>> semantics of 200 OK and Content-Location.  Specifically, since
>>> a book is not the same thing as its first chapter,
>>> http://example.org/WebDesign and 
>>> http://example.org/WebDesign?chapter=1 are distinct resources.
>>> If they are distinct we can't use 200 OK+CL to respond to one
>>> with the other.
>> 
>> But the first URI is not a book. You cannot define it as one
>> thing and then say its behavior doesn't fit that definition. It
>> is not that thing.
>> 
>>> I think I hear you saying that resources being distinct
>>> doesn't matter, that the notion of "representation" is much
>>> fuzzier than that.  I think you're saying that even though a
>>> chapter of a book and a book are different, it's fine to
>>> response 200 OK and give the text of the chapter as a
>>> representation of the book (assuming there was some negotiation
>> No, I am saying that the responses define the resource, not the
>> other way around. If you have distinct URIs with decidedly
>> different behavior, like your chapters, then they are of course
>> distinct resources. So is the resource that always responds with
>> a complete book. It is defined by what it does.
>> 
> 
> Right, that's our model.   We have resource like books, and we
> have resources like chapters.   We think of them as distinct types
> of things, and define specific behaviors for each of them, include
> headers they provide to indicate what they are, and restrictions on
> how they respond to GET, POST, etc.

What you have is actually a "book with chapters" resource.

You can think of them as diffferent things, but they are coming from
the same resource data which makes them only representations of one
resource.

> 
> We expect that sometimes some "books" will get to be quite large
> (many GB).  So we want the servers to be able to respond to a naive
> GET on a "book" with a 303 to the first chapter.   If it tried to
> stream the whole thing, we expect we'd have real problems.   We
> encourage clients to say what max response size they want; servers
> should use that information and send the biggest size they and the
> client are okay with.
> 

303 is saying "dont fetch this book A", fetch "book B instead".
Directing the client at a whole different "book" resource - not a
"chapter".

What you are trying to achieve with 2NN is respond "here is chapter 1
of book A". That is done with existing HTTP in either of two ways:

 1) by client requesting URI "/bookA" with Accept-Ranges:chapter and
server responding with 206, Range:chapter=1, and payload for that chapter.

 2) by server emitting 303 to URI "/bookA?chapter=1".
   then client re-requesting "/bookA?chapter=1"

#1 allows the amount of ranges replied by the server to adapt
depending on size or bandwidth available. It is quite powerful.

#2 signals that this book A may *only* be fetched chapter at a time,
beginning with 1. Fetching the /bookA without a chapter indicated is
"wrong" for this resource so try again with the chapter part.

To cover both clients who participate in #1 and clients who dont, both
methods should be implemented by the server. So clients not sending
the conneg Accept-Ranges:chapter header can get the 303 with a
Vary:Accept-Ranges on the server responses.

> 
> The one problem we see is that it's an extra roundtrip.    One
> could argue so what, but our application developers seem to care,
> so thus the idea of a 2NN which has the semantics of bundling the
> 303  and a subsequent 200 into one round-trip.
> 

It is only one extra round trip for old/legacy clients who do not
advertise range conneg to use option #1 above. These are the same ones
which will also not support your new 2NN status properly. They can be
just as easily updated to support Range conneg as to support 2NN, and
Range does not loose any caching benefits.

> As you've pointed out, this wont be able to use existing caches,
> and has some other caching weaknesses.
> 
>> resource. Range, for example, does not alter the representation;
>> it simply provides a range of that representation in the payload
>> of a 206. Conneg doesn't alter the representation either. It
>> merely selects one of the available representations.
>> 
> http://tools.ietf.org/html/rfc7231#page-51 section 6.3 doesn't say
> every 2xx has to be like that.

Every 2NN has to act properly when handled as a 200 by a client or
intermediary which does not yet support that 2NN special handling.

This means Vary:Prefer, and Prefer headers are mandatory in the server
responses for "/bookA" when the Range support method (#1 above) is not
used [for the 1.1 implementations] and something like Expires header
indicating stale content to prevent 1.0 implementations caching the
special payload.

>> representation to represent multiple resources. 3xx, in contrast,
>> says the request was not successful but this other thing might be
>> just as good.
>> 
>> There is nothing wrong with having a representation of a resource
>> that is a paged view. The only need is that something in the
>> representation data or metadata indicates that view, preferably
>> with prev, this, and next links. CL is a "this" link. The
>> resource is then partially defined by the fact that it offers
>> views of the overall state. All 200 responses. No big deal.
>> 
>>> If the HTTP WG really has consensus on that idea, I guess I can
>>> live with it, even though it's counterintuitive to me.
>>> 
>>> But how far does this go?    When is 200+CL not okay? Could the
>>> first sentence of the book be a representation of it?   How
>>> about the the first letter?   How about the 10th letter?    How
>>> about the 13th, 7th, and 22nd letters, in that order?    How
>>> about the first word of a different book?   How about the first
>>> sentence of a different book? How about the entire contents of
>>> a different book?    I don't see how you can draw a line here,
>>> with this way of thinking about it.
>> 
>>> To me, and the LDP WG, it's made a lot more sense to think of
>>> a chapter as simply being a different resource than the book,
>>> so if the server's going to give back a representation of the
>>> chapter, it can't use 200 OK.
>> 
>> The server is in control of what it's resources mean. If a
>> resource is not limited to being an entire book, then it isn't an
>> entire book. There's no reason to pretend otherwise.
> 
> LDP wants certain machine interoperability characteristics which
> are not in standard HTTP, so it's defining a more restrictive class
> of resources, which are less free to behave as they want.

I think you missed the point here.
 The LDP defines how the resource acts, how it acts defines how HTTP
is used to transfer it.

The more I read of this thread the more I see Range being what you
really want to do.

Amos

---

From: Sandro Hawke <[email-masked]>
Date: Mon, 08 Sep 2014 09:20:24 -0400

On 09/07/2014 10:48 PM, Amos Jeffries wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

It's common to have many URIs for resources all coming from the same 
database, of course.

> Directing the client at a whole different "book" resource - not a

Why can't it redirect to a chapter?

> server responding with 206, Range:chapter=1, and payload for that chapter.

I'm not familiar with why we rejected the Range design.   I'll let 
someone else answer with that, and/or look into it shortly.

>     then client re-requesting "/bookA?chapter=1"

That is in fact our primary mechanism.    But in one recent email, Roy 
said that wasn't okay.  So part of this thread is to confirm actually 
that protocol is okay.

> depending on size or bandwidth available. It is quite powerful.

(will reply separately, as above)
> "wrong" for this resource so try again with the chapter part.

Why are you being so restrictive?

What exactly would stop a client from doing a HEAD on /bookA and looking 
for rel=last if it wants to do reverse traversal?

What exactly would stop a server from providing /bookA instead of the 
redirect, if the clients gives different Prefer headers (with preferred 
sizes), or maybe the server load goes down?

> Vary:Accept-Ranges on the server responses.

Agreed that we need to have the 303 mechanism in place for clients that 
don't know to ask for paging/ranges themselves.   That's in our paging spec.

> Range does not loose any caching benefits.

Yes, if Range worked that would be great.   We'll check again on that.

> intermediary which does not yet support that 2NN special handling.

Can you point me to the part of a spec which says clients should treat 
all unknown 2xx codes as if they were 200?     I don't think that's how 
unknown 2xx codes are supposed to be handled.

> indicating stale content to prevent 1.0 implementations caching the

Yes

>   The LDP defines how the resource acts, how it acts defines how HTTP

I don't understand that sentence.   What does the second "it" refer 
to?   It looks like "the resource", but of course one doesn't transfer 
resources, one transfers representations.

> The more I read of this thread the more I see Range being what you

Could be.   We'll check on that again.

It's possible we did this design before realizing Range could be used 
with units other than bytes.   Do you know of any deployments with 
non-byte units?

Is there a way to make Range work with changing resource state? What 
happens if you have 100k units, and the client is reading 100 at a time, 
and an item gets inserted or deleted near the beginning.   It looks to 
me like the client would miss a boundary item or see a duplicated item. 
   (We've addressed this in paging by varying the page size when that 
happens.)    This seems like it'd be outside of what the folks designing 
Range were expecting, and so it wouldn't be properly handled.    Hoping 
I'm wrong....

        -- Sandro

>
> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUDRkEAAoJELJo5wb/XPRjQj4H/1he7mRI0TU0kU+F+eNd3SP8
> +TgrHlhIQ3frdjv+0OtYqeC/Xa1PxncMTNpGPDtr3tgk9QI5XiiSqfupRMoSbQ+1
> HtCzjLC6PucXjZ11IVj+XZzFJ4FU25+4upxAw6ejIjTdzNMo0O/3ZOVyWgOdKj3v
> mi/HFDx/i9P/1S3n6ebrINkoeSVwDqInvgQ0v46ktiQI+Mm7wTSzd8X8bCdRy/zn
> NiWwCIhU0O6g7F2YRs0zZT7JdgC7yfECkues6jQ8BHV120aSVCptCy27CLjwfcPU
> XaOKWS8OlqKnFp7yvNedrfeHsC1+21km5srbujs9IHPa8SFwv5u9fmmBGSmHz/s=
> =kbfK
> -----END PGP SIGNATURE-----
>
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Sep 2014 15:47:03 +0200

> unknown 2xx codes are supposed to be handled.

<http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.6.p.2>

> Range were expecting, and so it wouldn't be properly handled.    Hoping

If-Range. See 
<http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7233.html#rfc.section.3.2>.

Best regards, Julian

---

From: Sandro Hawke <[email-masked]>
Date: Mon, 08 Sep 2014 10:48:41 -0400

> <http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231.html#rfc.section.6.p.2> 

Thank you.    That would seem to kill 2NN Contents-of-Related as 
proposed.   I'm surprised no one has noticed/mentioned it before.

Am I reading it correct to imply that a client MAY treat any 2xx code 
(modulo caching) as a 200 simply by saying it "doesn't implement" the 
given 2xx?

I suppose it would work as 5NN, then.    Essentially, "I can't provide 
the content, since it's too large, but I am going to give you the first 
page of it."

> <http://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7233.html#rfc.section.3.2>.

I knew about that, thanks.  That allows one to detect that the resource 
state has changed, but not to safely continue downloading the rest of it 
without unrelated losses.  (In the case of changes to LDP resources, 
there are certain situations where it makes a lot of sense to continue, 
because the change is bounded in predictable ways.)

        -- Sandro

---

From: Sandro Hawke <[email-masked]>
Date: Mon, 08 Sep 2014 11:40:01 -0400

>proposed.   I'm surprised no one has noticed/mentioned it before.

Oh, sorry for the confusion, I forgot this is irrelevant, since we require servers to never send 2NN to clients unless the client first says it implements it.

      - Sandro

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 9 Sep 2014 09:44:18 +1000

On 9 September 2014 00:48, Sandro Hawke <[email-masked]> wrote:
>
> Am I reading it correct to imply that a client MAY treat any 2xx
> code (modulo caching) as a 200 simply by saying it "doesn't
> implement" the given 2xx?

That depends how the authors authored 2xx. AFAIK it's perfectly fine to
say: if you explicitly acknowledge support, you can't back out without an
error. But, yes, the implication is that anyone can (always or arbitrarily)
not support your code, and if that's a problem you have to account for it
in your spec.

> I suppose it would work as 5NN, then.    Essentially, "I can't
> provide the content, since it's too large, but I am going to give
> you the first page of it."

Depends if the underlying message is "I can't handle the big document" or
"You don't really want this big document".

I know of browsers (possibly historical) that handle all 5xx codes by
drawing a big red X symbol and writing our their own description of the
error, completely ignoring the response body, because apparently server
authors and site maintainers don't know how to talk to "real" computer
users. If you're happy for that as a possible fallback behaviour ...

To me it seems quite plain that this is a 3xx response; essentially the
server is second-guessing the client's request and effectively saying "Hey,
you said you want This, but you really want That, so I'll give That to you
and by the way next time you can get it There".

My suggestion is: use a new preference† in the request, for the server to
use as a trigger to respond with 303[Content-Location] + chapter body. Note
that just because Content-Location isn't defined for anything but 2xx,
doesn't meant it can't *become* defined for them.

This is completely aside from your particular issue, though, which is more
one of site architecture and the definition of resources.

† Either a new preference like "Prefer:contents-of-other", or a parameter
to an existing one, like: "Prefer:return=representation;include-redirect".
I'd defer to James on this.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 09 Sep 2014 07:25:39 +0200

> users. If you're happy for that as a possible fallback behaviour ...

AFAIR, this happened when the response body appeared to be "too short" 
(so it's easy to work around it).

Best regards, Julian