Re: See Other vs Contents of Related, was: 2NN Contents Of Related (303 Shortcut)

* Sandro Hawke <sandro@w3.org> [2014-09-05 07:33-0400]
> On 09/05/2014 06:35 AM, Mark Nottingham wrote:
> >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.

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.


> >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.

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


> >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.
> 
> 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.


>      -- Sandro
> 
> 
> >Cheers,
> >
> >
> >On 5 Sep 2014, at 1:01 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> >
> >>On 2014-09-05 11:51, Yves Lafon wrote:
> >>>On Fri, 5 Sep 2014, Julian Reschke wrote:
> >>>
> >>>>>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.
> >>>>>...
> >>>>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
> >>>>Prefer: contents-of-related
> >>>>
> >>>>HTTP/1.1 303 SEE OTHER
> >>>>Location: /other
> >>>>Preference-Applied: contents-of-related
> >>>>...
> >>>>
> >>>>(representation of /other)
> >>> 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.
> >>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
> >>
> >--
> >Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> >
> 

-- 
-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 Friday, 5 September 2014 13:01:48 UTC