W3C home > Mailing lists > Public > public-awwsw@w3.org > August 2009

HTTPbis and GET+303

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 31 Aug 2009 12:29:50 -0400
Message-ID: <760bcb2a0908310929t6640a407w6fe1ae89330b48ef@mail.gmail.com>
To: AWWSW TF <public-awwsw@w3.org>
Completing the task of bringing relevant HTTPbis text to the attention
of AWWSW (AWWSW ACTION-19):

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-07#section-8.3.4

8.3.4. 303 See Other

   The server directs the user agent to a different resource, indicated
   by a URI in the Location header field, that provides an indirect
   response to the original request.  The user agent MAY perform a GET
   request on the URI in the Location field in order to obtain a
   representation corresponding to the response, be redirected again, or
   end with an error status.  The Location URI is not a substitute
   reference for the originally requested resource.

   The 303 status is generally 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 requested resource
   does not have a representation of its own that can be transferred by
   the server over HTTP.  The Location URI indicates a resource that is
   descriptive of the requested resource such that the follow-on
   representation may be useful without implying that it adequately
   represents the previously requested 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 and thus entirely determined by the URI owner(s).

   A 303 response SHOULD NOT be cached unless it is indicated as
   cacheable by Cache-Control or Expires header fields.  Except for
   responses to a HEAD request, the entity of a 303 response SHOULD
   contain a short hypertext note with a hyperlink to the Location URI.

The main problem I see is "A 303 response to a GET request indicates
that the requested resource does not have a representation of its own
that can be transferred by the server over HTTP." which directly
contradicts the httpRange-14 resolution.  Suppose I have an ontology
that defines some number of URIs (i.e. tells you, as best it can, what
they should refer to). The URIs are not hash URIs. Now I am deploying
a server for those URIs. The TAG tells me that I can use 303, but
HTTPbis tells me I can only do a 303 if the server doesn't have a
representation of the referred-to resource. How on earth am I, the
server administrator, supposed to decide that question for every
resource? I have to do a cross product: For each representation that I
have, and for each resource in the ontology, is the representation a
representation of that resource? Only if no representation that I have
is of the resource can I do a 303. Answering this would require deep
scrutiny and understanding of the ontology, to no end.

There is also the problem that if a resource has to be a network
resource, then the non-network resource case is not covered. If my
preferred fix (change definition of "resource" to match RFC 3986) goes
through then this problem goes away.

This was discussed on www-tag. If someone could summarize the battle
lines I'd appreciate it.

Jonathan
Received on Monday, 31 August 2009 16:30:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 31 August 2009 16:30:35 GMT