- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 30 Aug 2011 10:22:52 +0200
- To: Jonathan Rees <jar@creativecommons.org>
- CC: www-tag@w3.org
On 2011-08-29 17:33, Jonathan Rees wrote:
> I've revised this document in place:
>
> http://www.w3.org/2001/tag/2011/09/referential-use.html
> ...
"The httpRange-14 resolution suggested the 303 redirect response to GET
as a way out for those wanting to use hashless (fragment-free) URIs to
meet need S1. The 303 status signals the absence of retrieval behavior
for the URI. This method provides the desired syntax, but makes
discovery more difficult than S2 because it's hard for some publishers
to deploy and because of performance worries (typically two network
round trips required instead of one per S2)."
The last part might be fixable; a server can return the representation
of the redirect target as payload, and by including a Content-Location
header field the user agent could find out that it doesn't need to fetch
the identified resource.
Example:
C: GET /foo HTTP/1.1
Host: example.com
S: HTTP/1.1 303 See Other
Content-Type: text/plain
Location: /description-of-foo
Content-Location: /description-of-foo
This is the description of http://example.com/foo
Note that the semantics for Content-Location have been clarified in
HTTPbis, see in particular
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-16.html#identifying.response.associated.with.representation>.
A small problem is that the description of 303 has:
"Except for responses to a HEAD request, the representation of a 303
response SHOULD contain a short hypertext note with a hyperlink to the
Location URI." --
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-16.html#rfc.section.8.3.4.p.4>
But that could be fixed.
Best regards, Julian
Received on Tuesday, 30 August 2011 08:23:32 UTC