i58: What identifies an HTTP resource

I could use some clarification on this issue [1], mostly because I've
spent the last year learning the hard ways why the 'query' component
needs to be considered part of the resource identifier (proper cache
invalidation tops that list). I have no problems with the ticket or the
first proposal therein which says "The semantics are that the identified
resource is located at the server listening for TCP connections on that
port of that host, and the Request-URI for the resource is abs_path plus
the optional query parameter (Section 5.1.2)."

But then things start to unravel. There are two issues I'm stumbling
over:

 1. The next comment on that ticket seems to directly contradict my
hard-won position. It says "...the proposed new definition of "resource"
implicitly demands that if POST
http://www.example.com/article/23?date=2008-10-20&author=mathew is a
valid request, then GET
http://www.example.com/article/23?date=2008-10-20&author=mathew should
also be a valid request, a request to get the named resource that you
just posted. This is not the case for most existing software."

But 2616 says, "the POST method is used to request that the origin
server accept the entity enclosed in the request". If you didn't include
an entity, then there is no implicit "get the named resource that you
just posted"--you didn't POST a resource (or even a representation of
one). Components of the URI are clearly not entities according to the
spec (although they may be considered so in malpractice).

Even if you did include an entity, POST is not PUT. RFC 2616 also says,
"the URI in a POST request identifies the resource that will handle the
enclosed entity," which to my mind implies no connection between POST
and GET on the same URI. There *is* such a connection between PUT and
GET, but not POST.

I can understand the desire to have the spec codify existing practice.
But it should also guide inexperienced developers toward scalable
network systems. Moving POST entity data into the URI should be
discouraged, not enabled, IMO, if HTTP is to continue to be guided by
the REST style.

 2. The latest http draft (06) changed the "Request-URI" production to
"request-target". Julian R. mentioned that "the Request-URI ... [is] not
really a URI" [2].  I'd like to hear more about that point-of-view--with
the exception of "*", all the valid values look like URI's to me (albeit
a subset that requires a different parser for e.g. "//abc", which is
ambiguous in general but not in HTTP).

Correct me if I'm wrong, because I'm baking some of these opinions into
one of the more well-used Python HTTP servers and I'd rather get it
right.


Robert Brewer
fumanchu@aminus.org

[1] http://wiki.tools.ietf.org/wg/httpbis/trac/ticket/58
[2] http://markmail.org/message/76z3abkq2pagcmpw

Received on Thursday, 12 March 2009 17:18:36 UTC