Re: Proposed HTTP SEARCH method update

> On 12 May 2015, at 01:25, Zhong Yu <zhong.j.yu@gmail.com> wrote:
> 
> 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.

That is good, because we don't want to modify the semantics of GET, 
just extend the types of range requests allowed by HTTP 1.1 to 
not just allow byte ranges but more semanitcally rich partical content
requests.

I note that RFC7233 on Range Requests allows these to be extended

[[
2.2.  Other Range Units


   Range units are intended to be extensible.  New range units ought to
   be registered with IANA, as defined in Section 5.1.

     other-range-unit = token
]]


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

yes, and there is no intention to change it.

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


It says very precisely that there are "no defined semantics", which is
not the same as "never can have a defined semantics".  This is good
protocol design: don't close doors you don't need to. 

Furthermore if the server drops the body, everything functions exactly
right, just as it does when a server ignores the range request headers.

Henry

> 
> 
> Zhong Yu
> bayou.io

Social Web Architect
http://bblfish.net/

Received on Sunday, 17 May 2015 09:14:27 UTC