Re: i58: What identifies an HTTP resource

On Mar 12, 2009, at 10:17 AM, Robert Brewer wrote:

> 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:

I just added a comment to issue 58.

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

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

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

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

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

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

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

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.

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

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

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

Received on Thursday, 12 March 2009 20:59:19 UTC