Re: New Version Notification for draft-snell-search-method-02.txt

Am 12.09.2020 um 03:13 schrieb Amos Jeffries:
> ...
> Looking through the draft for SEARCH it appears to me that the intended
> use makes responses to it effectively non-cacheable by default. The
> requirement not to invalidate previous responses does not help with that
> - just confuses things further.
>
> There is also the need for an Accept-Search mechanism to negotiate its
> use. If negotiation is needed, then are we perhapse better off instead
> negotiating the fact that GET payload is usable?
> ...

I don't think that negotiation is stricly needed.

> Would a hop-by-hop header that allowed a server to inform a client how
> many bytes of GET payload it will accept can resolve these use cases?

That would require every hop to support that new signal, right?

...I am skeptical about GET-with-payload, considering the known interop
issues and the fact that we've been telling people for years not to try
it. *If* we can make it work without touching too many components, that
would be interesting. But can we?

Best regards, Julian

Received on Monday, 14 September 2020 08:07:13 UTC