Defining a new HTTP method: HTTP SEARCH

Re:Defining a new HTTP method: HTTP SEARCH by dejj on Friday April 16, 2021 @06:46PM (#26839872)

> Right now the spec does not define the result of this query as cacheable. It's not completely clear why

That was the unique selling point of SEARCH over POST though.

How about using the Range header with a custom value domain instead?

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by compressedgas on Friday April 16, 2021 @07:43PM (#26840266)

I thought the point was that SEARCH would be idempotent whereas POST is not.

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by pii on Friday April 16, 2021 @08:31PM (#26840563)

Searching already isn't idempotent

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by remram on Friday April 16, 2021 @10:26PM (#26841138)

idempotent != immutable

Search is idempotent in the sense that it doesn't change anything on the server, other than mutating caches (which should be idempotent).

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by naniwaduni on Saturday April 17, 2021 @02:09AM (#26841971)

Pretty sure nobody cares about ensuring that e.g. a proxy knows that nothing will go wrong if it issues a search twice. It's the reverse direction that matters.

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by remram on Saturday April 17, 2021 @11:48AM (#26845127)

Yes, this is why search is idempotent

[ Parent | on HN ]

Re:Defining a new HTTP method: HTTP SEARCH by pii on Saturday April 17, 2021 @01:01PM (#26845725)

Oh TIL. Thanks

[ Parent | on HN ]