- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 4 Nov 2020 14:36:19 +0100
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: ietf-http-wg@w3.org
Am 04.11.2020 um 14:24 schrieb Poul-Henning Kamp: > -------- > Julian Reschke writes: >> Am 04.11.2020 um 03:40 schrieb Sawood Alam: > >>> cases. Also, 204 is a success response, which means a client might >>> repeat the request, while a 4xx response would suggest that there is no >>> point in repeating the request without making changes to it. >> >> If the request target exists, and accepts and processes the query, the >> response ought to be a 2xx, no? > > Any librarian will tell you that "Found" is much simpler than > "Not found", which has a lot of possible semantics: > > Not found, though it should have been. > > Not found, and will never be found. > > Not found, but will certainly be found sometime in the future [($time)]. > > Not found, and cannot possibly be found until ($time) > > Not found here, but try asking ($uri, [$query_params]) > > Not even looking, you have been asking too many queries recently > > Not telling, (temporary/permanent/authorization needed) > > Found, but you cant have it (temporary/permanent/authorization needed) > > ... > > It might be a good idea to hash out a couple of general mechanisms > in the spec, to provide mechanisms for traffic/load-engineering, > at the very least something like "Dont-repeat-this-SEARCH: <seconds>" ? That's all very interesting, but why is this relevant now, but not for existing uses of POST we want to replace? (also: <https://greenbytes.de/tech/webdav/rfc6585.html#status-429>) Best regards, Julian
Received on Wednesday, 4 November 2020 13:36:43 UTC