- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 15 Sep 2020 09:32:05 +1200
- To: ietf-http-wg@w3.org
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. >> 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. Amos
Received on Monday, 14 September 2020 21:38:08 UTC