303 and HTTPbis

I was taken by a doubt about wether the arguments I put forward about 303's 
 with respect to ISSUE-74, namely that a 303 WebID required one more 
HTTP message exchange over and above hash urls, was still valid for http-bis.
We had noticed before that the http-bis no longer has the vocabulary on caching
the response that http1.1 has. Here is the relevant spec text.


[[
6.4.4 303 See Other

The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.

This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached independent of the original request.

A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.

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

But this makes clear that even for HTTPBis there are still two HTTP Connections 
required to get from a non hash WebID to a WebID Profile:

1. The first GET on the WebID returns a 303 with a Location header
2. The second GET on the Location retrieves the Profile Document

This means that the advantage of 303s with respect to caching of the content
of 303s goes only so far as to allow a client to cache a 303 header (which means
that the time to live of the redirect for example makes some sense) But the
main inefficiency of redirects still remains. Even SPDY could not resolve this
problem.

Henry

[1] https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#status.303

Social Web Architect
http://bblfish.net/