- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 14 Sep 2020 10:06:59 +0200
- To: ietf-http-wg@w3.org
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