Subject: Re: Call for Adoption: SEARCH method

From: "Juan Barriteau" <[email-masked]>
Date: Sun, 04 Apr 2021 14:05:23 -0400

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 ([email-masked]), 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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 6 Apr 2021 16:11:25 +0200

Am 04.04.2021 um 20:05 schrieb Juan Barriteau:
> 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...

Welcome to this Working Group. You sent feedback, so you aren't a
stranger anymore :-)

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

The reason for picking "SEARCH" in the initial draft was that this
method name is already registered, so we don't have to add yet another
one with essentially the same semantics. And furthermore, there's
already code out there which understands that SEARCH is safe and thus
can be safely retried.

That said, some people are unhappy with that, so the name of the
internet draft deliberately was chosen so that *if* we pick a different
name we don't end up with a funny mismatch.

Best regards, Julian