Subject: i58: What identifies an HTTP resource

From: "Robert Brewer" <[email-masked]>
Date: Thu, 12 Mar 2009 10:17:55 -0700

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
[email-masked]

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 12 Mar 2009 13:58:47 -0700

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

I just added a comment to issue 58.

> just posted. This is not the case for most existing software."

Just because someone made a comment doesn't imply that the
comment is correct.

> spec (although they may be considered so in malpractice).

POST doesn't have any implication on GET, for either version of
the wording for that section.

> and GET on the same URI. There *is* such a connection between PUT and

They have a corresponding definition.  However, there is no requirement
that an allowed PUT will also imply an allowed GET on the same URI.

> discouraged, not enabled, IMO, if HTTP is to continue to be guided by

HTTP/1.1 is designed (within the limitations of backwards compatibility)
so that the protocol is optimized for a RESTful application architecture
(i.e., whether or not it is optimized for other architectures was simply
not considered important).  However, that does not imply that HTTP is
limited to RESTful applications.  HTTP is designed to be a very flexible
interface protocol as well, so the definitions in the spec have to
match how the interface is used regardless of architectural style.

> ambiguous in general but not in HTTP).

I made a mistake (in prior RFCs) by using the ABNF term, which
corresponds to several different forms of reference, in the prose
descriptions for the URI target of the request.  In the next version
we will probably use "requested URI" or "URI target" or something
similar (to be defined in p1) when talking about the entire URI
as understood by the client, and only use the ABNF terms for defining
how that URI is broken down into components and indicated within
the HTTP messages.

Sorry, I had planned to have that done before 06.

....Roy