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

Am 14.09.2020 um 23:32 schrieb Amos Jeffries:
> On 14/09/20 8:06 pm, Julian Reschke wrote:
>> 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.
>>
>
> There is no implicit default content-type documented. Just the
> Accept-Search header to negotiate one, and a passing reference to extra
> requirements when XML is used.

Well, there is no negotiation for POST either (except for returning 406,
which will work here as well). Where's the difference?

>>> 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?
>
>
> I think this is the only way GET-with-payload would actually work
> reliably while those known issues exist. Origin that support it sending
> the header and middleware that don't dropping the header. So clients
> receiving the header know they can use GET payloads.

So we would need to modify intermediaries and software components. I
believe this is a non-starter.

Best regards, Julian

Received on Tuesday, 15 September 2020 03:47:01 UTC