- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Sun, 15 Jun 2014 18:19:07 -0400
- To: public-ldp-wg@w3.org, www-tag@w3.org
- Cc: Jeni Tennison <jeni@jenitennison.com>, John Arwe <johnarwe@us.ibm.com>
I think the 2NN draft is ready for final review: <http://www.w3.org/2014/02/2xx/draft-prudhommeaux-http-status-2NN.xml> Many thanks for Jeni's/TAG's spec review at <https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md>. I've changed the text a lot in response, and drafted these responses. Following are responses to the TAG comments <https://github.com/w3ctag/spec-reviews/blob/master/2014/04/http-209.md>. These use the terms "related resource" and "expected response" as defined in Section 2 of the updated 2NN draft. 1. doesn't work in Chrome: Chrome has issues with stylesheets links with relative URLs. I've made it absolute, and I believe that early in the IETF process, the document will get HTML-ified, text-ified and maybe even tex-ified. 2. s/209/2NN/ done 3. s/Location/Content-Location/g declined, both Location and Content-Location may appear in the same 2NN response (example in the 2NN draft). The Location identifies the target of the redirection and the Content-Location identifies a direct URL for any conneg that (would have) happend on a GET of the Location header value. 4. add packaging use case done 5. clarify interpretation of headers, e.g. Link applies to orig URL. All except Location apply to related resource. If we make e.g. Link apply to the original URL, we'll have no way to communicate the link headers associated with the related resource. There's an example with an expected response with a Link header. 6. recommend Link header à la Link: <http://example.com/meta>; rel=describedby As stated in 5, Link, like all headers, applies to related resource. We could have used a REV= link from the related resource back to the original URL, but it has been deprecated. Punting for now means not trying to define a prescrive behavior which tells people that they should use link relationships which may have not yet been invented. Of course, people are free to add what Link headers they want. 7. for security, don't extend caching semantics to related resource waffling here I stipulated that it can be done only with out-of-band trust, which is analogous to Content-Location. It could be argued that the C-L text only *implies* caching with the text "the origin server claims that the URI is an identifier for a different resource corresponding to the enclosed representation". I come right out and say "If the client has out of band reason to trust the server's claim that the same operation performed on the value of the Location header would have elicited the same response, they may additionally cache a 200 response for the requested operation on value of the Location header." That seems analogous to the implications of the C-L text, albeit a bit more direct. 8. define Accept-Related: describedby, provenance I think your goal was that "Accept-Related: first" (or Samdro's proposed "Prefer: follow-link rel=first") would leverage the Link rel registry to codify what relationship one wants to follow from the initial resource. This exceeds the current expressivity where one recieves an e.g. 303 with a single resource in the Location. The parameterized Accept-Related would be a shortcut for an exchange where the server returned a 303 with maybe no Location but instead multiple Link headers and the client did a GET on one of them. I think this is fascinating and useful, but I don't think we want to predicate 2NN on a rather complex expressivity. It should be easier to explain with the single "Prefer: contents-of-related" which says "please send me a 209 for the (only) resource you would have redirected me to." Once in place, other RFCs can leverage 2NN for a growing network of coded link relationships, maybe involving even requests like "follow-link rel=first,rel=next" to get the 2nd page. 9. say how 2NN works for other methods Currently worded in terms of "the same method executed on the related resource" so I think we're covered without having to dream up a lot of use cases. The 2NN spec references the HTTPbis spec for a use case for POST. PUT, DELETE, ACCEPT and CONNECT become progressively harder to think about. There's no restriction in HTTPbis about where you might see a 303 but I didn't want to specifically prohibit 2NN for use cases I can't predict. 10. Update HTTPbis ref done Potential issues: - As mentioned above, 2NN is defined in terms of any response which would yield a Location header. Maybe we should say "only 201 and 3xx" or maybe "only 303". - The caching makes explicit some (trusted) caching implications that are only implicit in the HTTP spec. - A few folks have wanted the client to ask for following specific links but I think that's a different spec, written in terms of Link headers on 3xx responses. -- -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 Sunday, 15 June 2014 22:19:13 UTC