Re: Proposed HTTP SEARCH method update

On Sun, May 10, 2015 at 7:04 AM, henry.story@bblfish.net
<henry.story@bblfish.net> wrote:

> There are two possibilities here, both allowed by the current spec.
>  1) GET with Query: and Query-Type: header ( the second one giving the mime
> type of the header
>  2) GET with Content-Type header and body.

I don't think you'll have *any* luck trying to modify the semantics of
GET. Your best bet is still to define a new method.

Sure, the server and the client can construct any well-formed message
and assign whatever meaning to it. It'll work most of the times. You
can even construct ill-formed messages. Heck, why use HTTP any all:)

But the question is, do others agree to this semantics too, and do you
care about their existence. Regardless of what the spec says, GET has
a widely accepted and understood semantics, any deviation from it can
and will cause interoperability problems with some deployments.

For the interest of this working group, we can nevertheless discuss
the wording of the spec with regard to this use case. The following
statement in RFC7231

> A payload within a GET request message has no defined semantics

is broad and vague, how do we apply it here? I would rather take an
extreme interpretation - A payload in a GET request is completely
meaningless, it can be dropped without affecting the semantics of the
request; therefore we should not use it for any semantics purposes if
any 3rd party (besides client and server) is involved.


Zhong Yu
bayou.io

Received on Monday, 11 May 2015 23:26:16 UTC