- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 19 Nov 2020 10:10:52 +0100
- To: Greg Wilkins <gregw@webtide.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Am 19.11.2020 um 09:19 schrieb Greg Wilkins: > ... > Then why don't we just define the semantics of GET's may have bodies. > ... My understanding is that we won't be able to do that, because it would not work everywhere. If we found out that not to be true, it would be an alternative. > A client that wishes to send a SEARCH or a GET with a body will equally > have to expect a 4xx if something in the path doesn't expect either. > > The main difference is that a GET with a body may receive a response > that simply ignored the body and the client may not be able to determine > that. But then equally it is not possible to tell if a SEARCH method > has been simply routed to a GET implementation and the body equally > ignored. If this is a concern, then perhaps defining a response header > that indicates the request body was considered is a better way forward? The subtle difference here is that a server that ignores the body on GET currently is conformant, while a server that treats SEARCH as GET is buggy. The suggestion with the response header field although is interesting. Best regards, Julian
Received on Thursday, 19 November 2020 09:11:06 UTC