Re: Proposed HTTP SEARCH method update

On 20/05/2015 12:29 p.m., Zhong Yu wrote:
> On Tue, May 19, 2015 at 6:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>> Ok. I’ll bite. Why doesn’t DELETE do the same thing?
> 
> 
> Just today, I saw a case [1] where a popular client sends body in
> DELETE, and a popular server outright rejects DELETE with body.
> 
> In a messy situation like this, we would naturally seek an authority
> or an arbitrator. However, the good people of this working group do
> not seem to be interested in playing that role. They are more
> interested in documenting the best practice that maximize
> interoperability. They will give advices and recommendations, but they
> are not here to issue rulings or give permissions.

There is a very good reason for that. We do not know of any use case why
a body would be needed on DELETE. Neither do we know of any good reason
why one should be rejected. So it is left as a place where future
standards can define meaning if a case is ever found.


Anyhow the [1] situation is different.

The curl test being run on the server sends it the 9-byte long string
"test.json" - as opposed to the JSON data inside it which the API
expected.  I believe the server 400 message complained about may
actually be the server rejecting invalid data format.

==> Throwing an invalid syntax inside the payload does not help debugging.


If the server were simply rejecting based on any payload existence it
would be clearly violating RFC 7230 section 3.3. Which states a payload
may exist on any method ... "even if the method does not define any use
for a message body.".

"
   The presence of a message body in a request is signaled by a
   Content-Length or Transfer-Encoding header field.  Request message
   framing is independent of method semantics, even if the method does
   not define any use for a message body.
"

RFC 7231 DELETE method only states that there is no defined semantics
for a payload and that sending a custom one may cause problems.



> 
> That's probably the misunderstanding here by people who want GET with
> body - they think this working group can be an authority that makes it
> happen.

Perhapse. AFAIK we have a good record on setting those bad assumptions
straight though.

> 
> Therefore I think this topic (GET+body) is out of the scope. You do
> not need to seek permission from the working group, you will not get
> any. You will not get an opposite "decree" either. You can go ahead
> and do it, against all advices, and if it becomes a huge success, the
> working group will accept the reality and document it down.

Discussing it is very much in scope IMHO. GET is a part of HTTP, any
attempt to give its payload meaning needs scrutiny by persons currently
members of this WG and probably other WG as well.

There have been several proposals that have a lot of merit. Henrys' is
one of the better ones. The problem is how the legacy infrastructure
will handle it. Which is where this WG comes in with the advice. Note
that the change between RFC 2616 and RFC 7231 regarding GET body was
preparation for one day having bodies work on GET. We are just nowhere
near that being ready to use yet.

> 
> [1] http://stackoverflow.com/questions/30334776/servlets-3-1-how-to-handle-body-in-delete-request
> 
> Zhong Yu
> bayou.io
> 


Amos

Received on Wednesday, 20 May 2015 04:43:51 UTC