- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 15 Sep 2020 05:46:46 +0200
- To: ietf-http-wg@w3.org
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