Subject: Issue i17 (Revise description of the POST method)

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Jun 2007 23:10:31 +0200

Hi,

I just realized that by resolving issue i17 
(<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i17>) by 
relaxing the semantics of POST, we may have broken the definition of 
PUT, which says 
(http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-02.html#rfc.section.9.6.p.3>):

"The fundamental difference between the POST and PUT requests is 
reflected in the different meaning of the Request-URI. The URI in a POST 
request identifies the resource that will handle the enclosed entity. 
That resource might be a data-accepting process, a gateway to some other 
protocol, or a separate entity that accepts annotations. In contrast, 
the URI in a PUT request identifies the entity enclosed with the request 
-- the user agent knows what URI is intended and the server MUST NOT 
attempt to apply the request to some other resource. If the server 
desires that the request be applied to a different URI, it MUST send a 
301 (Moved Permanently) response; the user agent MAY then make its own 
decision regarding whether or not to redirect the request."

Now that the spec basically specifies how POST is used in the wild, is 
the comparison with POST in the definition of PUT still correct?

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 04 Jun 2007 10:38:50 +0200

sön 2007-06-03 klockan 23:10 +0200 skrev Julian Reschke:
> "The URI in a POST 
> protocol, or a separate entity that accepts annotations."
> 

Think so. Why? I don't see any conflict.

But also don't see much reason why PUT should talk about what POST does
instead of just focusing on what PUT does..

Proposal: Delete the text in PUT which describes POST. It's redundant
with the description of POST and the two is just next to each other
adding very little value.

From:

The fundamental difference between the POST and PUT requests is
decision regarding whether or not to redirect the request.

To:

The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a PUT
request identifies the entity enclosed with the request -- the user
agent knows what URI is intended and the server MUST NOT attempt to
apply the request to some other resource. If the server desires that the
request be applied to a different URI, it MUST send a 301 (Moved
Permanently) response; the user agent MAY then make its own decision
regarding whether or not to redirect the request.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Jun 2007 17:39:08 +0200

Henrik Nordstrom wrote:
> ...

Good catch. The description of PUT currently contains text that we 
previously removed from POST (so this is a good example why looking at 
errata in isolation may be problematic).

Getting back to my original point: with the resolution of Issue i17, we 
have relaxed the constraints of POST so that the definition actually 
matches reality. I don't think it was intended to change the definition 
of PUT, though.

Thus, we may want to change

	"The fundamental difference ..."

to something like

	"One difference...."

because now there are more fundamental differences than before, right?

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 04 Jun 2007 22:06:21 +0200

> matches reality. I don't think it was intended to change the definition 

I don't see it. Can you elaborate.

The difference between PUT and POST is just that. The Request-URI in
POST identifies the location of the resource responsible for processing
the enclosed entity, while the Request-URI of PUT identifies the
intended location of where the enclosed entity should be published.

How the server processes a POST is entirely application dependent and
outside the specifications.

Note: HTML defines data format for posting forms results, but thats just
one application of POST.

> because now there are more fundamental differences than before, right?

I'm fine with both wordings. But it is the most fundamental difference
between the two methods.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Jun 2007 22:14:43 +0200

Henrik Nordstrom wrote:
> ..

OK, let me try to rephrase it.

Is it OK to use POST for XML-RPC? If yes, *could* I use PUT instead?

I didn't think so.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 04 Jun 2007 23:02:00 +0200

mån 2007-06-04 klockan 22:14 +0200 skrev Julian Reschke:
> Is it OK to use POST for XML-RPC?

Yes, of course. XML-RPC is a perfect example where the Request-URI
identifies a data-handling process responsible for processing the
XML-RPC call and returning the result in a 200 response.

And is allowed by RFC2616 even if ther is that bit of confusing wording
about the submitted data being a subordinate.. The subordinate wording
is technically not that wrong, just confusing and makes completely wrong
associations which makes it a bad choice for describing the relation.

>  If yes, *could* I use PUT instead?

Not if you want the XML-RPC to be processed by the server and expect to
have the result returned.

I don't see how the definition of PUT could make anyone think that PUT
would be the appropriate method for XML-RPC calls to be processed online
by the server.

But PUT is the appropriate method you want to publish/store the XML-RPC
call as such (the XML-RPC request entity blob, not the result or the
XML-RPC call) as an entity on the server, at the location identified by
the request URI. In the XML-RPC context possibly for later batch or
offline processing by other agents, or simply as a permanent record of
the call contents.

In my eyes the RFC2616 PUT refeferences to POST behavior is perhaps
closer to the current POST definition than the original. Lets look at
that text again in isolation, should we:

   The URI in a
   POST request identifies the resource that will handle the enclosed
   entity. That resource might be a data-accepting process, a gateway to
   some other protocol, or a separate entity that accepts annotations.

No "subordinate" crap to confuse what is being talked about, and with
the "data-handling process" part which opens for pretty much any data
processing you might imagine.

It's actualy a quite good sentence, except that it has nothing to do
with PUT.. It can be moved straight up to POST with no changes imho. And
XML-RPC is a perfect match for the "data-accepting process" gategory.

Again, I don't quite get what it is you are worried about here. The
"data-accepting process" is just about anything which accepts data and
processes it in some manner..

What about the text is it you have concerns with?

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Jun 2007 23:12:57 +0200

> What about the text is it you have concerns with?

Seems I have trouble getting my concerns across :-).

This is related to a discussion we had a few weeks ago over on Atompub, 
where there was an argument whether a server can just drop parts of the 
PUT body, or actually implement PUT as some kind of PATCH (where PUT 
would only modify parts of the existing resource).

I *think* the consensus was that when RFC2616 says "store" it really 
means "store", so -- in general a server should not just do a partial 
update of the request being identified.

rfc2616bis-02 relaxes the original definition of POST, so my concern is 
that by PUT referencing POST we also have relaxed the definition of PUT 
as well (making it: the server may do *anything* it wants).

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 05 Jun 2007 00:07:08 +0200

> would only modify parts of the existing resource).

My understanding of PUT:

You can use PUT to patch entities by doing a ranged PUT using
Content-Range together with If-Match using a strong validator. But I
don't expect many implementations to support this and would also expect
several to silently fail to do it properly even if there is a MUST
requirement to error if not understood.. (9.6 PUT, first paragraph, last
sentence)

Note: As written the specs do not allow multipart/byteranges to be used
in PUT.

> update of the request being identified.

Yes.

> as well (making it: the server may do *anything* it wants).

No, I don't see that PUT has been relaxed in any manner by the POST
changes. The definition is quite strict about the meaning of the request
entity in PUT.

But then I also don't really consider the POST changes as relaxing the
definition of POST, just cleaning it up to be more consistent with
itself. And I also consider the POST reference in the PUT description as
informative to remind the reader that there is a related method, and not
part of the formal definition of PUT. There is no SHOULD/MUST/MAY in
there..

Regards
Henrik

---

From: David Morris <[email-masked]>
Date: Mon, 4 Jun 2007 19:31:44 -0700 (PDT)

The proposed revision to POST removes language I considered confusing at
best when 2626 was written. I had to twist my brain sideways to
rationalize subordinate with reality. Since 'subordinate' made no
practical contribution to interoperabilty, the revisions don't relax the
definition of POST.

In the end, an application which uses POST (or PUT) isn't created in a one
sided vacumn. The server processing component and the HTML/XML/JS, etc.
which interacts as a client are created by the 'same' entity in
coordination with each other. Data submitted to a process is subordinate
to the will of that process. Dah!

Dave Morris