W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: Call for Adoption: SEARCH method

From: Juan Barriteau <juan@barriteau.net>
Date: Sun, 04 Apr 2021 14:05:23 -0400
Message-ID: <Mailbird-74d3d62d-3683-4ead-abd4-ce51dd007262@barriteau.net>
To: "" <ietf-http-wg@w3.org>
Maybe mine are silly questions, I'm pretty sure I have a lack of context, but I'll risk it, just don't be too harsh with the stranger... 

Why not simply name SEND this method which has body but is not intended to change the state of the resource? I perceive a method named like this as a natural companion for the current standard methods.

If I were a server I would feel comfortable receiving a request preceded for a SEND and proclaiming "my body contains a search query" or a SEND saying "my body contains some equations to solve".

But as a server I neither would have problems receiving those same requests simply using SEARCH and CALC methods respectively, I got it, having a SEARCH method could be efficient from the application perspective because the semantic obviousness dispenses the need to explain what is the body for, same as having a CALC method would do.

But, Isn't it better to standardize something more "general" like the SEND and emphasize and reinforce the existing permit to use non-standard methods? as far as I understand, and please, excuse me and bring me to the light if I'm wrong, I should be able to use SEARCH, CALC, CONVERT, BEAUTIFY, COMPRESS, ENCRYPT, TRANSFORM, EVALUATE, ARMONIZE, CONVERT, NORMALIZE, TRANSLATE, PRETTIFY, ANAGRAMIZE, MINIFY, COMPILE, CONCATENATE, MAKETEA or any other non-standard method if it works for me and and my resources, that without worrying about firewalls and servers rejecting them or the OpenAPI Initiative not supporting them. Is it like that?

Best regards,

Juan

> Am 02.12.2020 um 04:52 schrieb Tommy Pauly:
> > Thanks for all of the feedback and detailed discussion on draft-snell-search-method!
> >
> > Based on the input, we believe that the working group has consensus to adopt this item. Many of the > details, including the method name, will continue to be discussed as this is adopted, but the scope of > work is to define a method that has the behavior of a GET with a body.
> >
> > Best,
> > Tommy & Mark
> > ...
> 
> I've been sitting on this until the http-core drafts were finished (for
> some value of "finished").
> 
> Now that these are out, I'v republished the document that was adopted as
>   draft-ietf-httpbis-safe-method-w-body-00:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the HTTP WG of the IETF.
> >
> >         Title           : HTTP SEARCH Method
> >         Authors         : Julian Reschke
> >                           Ashok Malhotra
> >                           James M Snell
> > Filename        : draft-ietf-httpbis-safe-method-w-body-00.txt
> > Pages           : 8
> > Date            : 2021-03-31
> >
> > Abstract:
> >    This specification updates the definition and semantics of the HTTP
> >    SEARCH request method originally defined by RFC 5323.
> >
> > Editorial Note
> >
> >    Discussion of this draft takes place on the HTTP working group
> >    mailing list (ietf-http-wg@w3.org), which is archived at
> >    https://lists.w3.org/Archives/Public/ietf-http-wg/.
> >
> >    This note is to be removed before publishing as an RFC.
> >
> >    Working Group information can be found at https://httpwg.org/; source
> >    code and issues list for this draft can be found at
> >    https://github.com/httpwg/http-extensions/labels/safe-method-w-body.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-00.html
> 
> (note that I have used a draft filename that makes it clear the method
> name is really not cast in stone yet)
> 
> Best regards, Julian
Received on Tuesday, 6 April 2021 08:35:41 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 6 April 2021 08:35:43 UTC