Re: ACTION-587 Prepare issue-57 and issue-63 documents for TAG members to discuss at Sept F2F

On 2011-08-29 17:33, Jonathan Rees wrote:
> I've revised this document in place:
> ...

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


C: GET /foo HTTP/1.1

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

Note that the semantics for Content-Location have been clarified in 
HTTPbis, see in particular 

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

But that could be fixed.

Best regards, Julian

Received on Tuesday, 30 August 2011 08:23:32 UTC