- From: Nathan <nathan@webr3.org>
- Date: Tue, 25 Jan 2011 01:08:51 +0000
- To: AWWSW TF <public-awwsw@w3.org>
Hi all, I'm really struggling with something, which I can only call "conditioning", if you remember recently there was a proposal to leverage Content-Location so that one could GET 200 OK on slash URIs, tonight I went back to look at that again, wrote a big reply then had to stop myself. Content-Location: For a GET or HEAD request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation and the representation selected for this response can also be found at the identified URI. I did it again, I read that as: For a GET or HEAD request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation and the representation selected for this response is identified by the URI in the Content-Location header. Then I realised, this is what caused the suggestion of the Content-Location approach in the first place. Takeaways, When you deal with HTTP: - resources /sometimes/ have an identifier - a representation is /sometimes/ associated with an identified resource (one for which you have a URI) - a representation /never/ has an identifier. The Content-Location approach can't work, because the Content-Location doesn't identify a representation. Nathan
Received on Tuesday, 25 January 2011 01:10:41 UTC