- From: Michael Toomim <toomim@gmail.com>
- Date: Thu, 31 Oct 2024 18:35:24 -0700
- To: Josh Cohen <joshco@gmail.com>, Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
On 10/31/24 3:03 PM, Josh Cohen wrote: > Perhaps you should use both. Much like a regular web server if we > have the resource we return it, if we don't have it, but know where it > is we send a 3xx. If we don't have it and don't have any known > address for it, then we return a 404. The problem is that 404 says "this resource does not exist." That means it has been deleted. The client and caches should react by deleting the resource. We don't want anyone to delete it. It's not deleted. It just needs the client to look around a bit more, and the server isn't in charge of where that is. This is a new case because it enables distributed state. In distributed systems, you want to avoid coordination. The existing codes assume that the server is coordinating where copies of the state exist. We want to enable systems where peers can independently choose how much history to store. This results in server semantics that we haven't seen before, so our status codes will have slightly different semantics than we are used to.
Received on Friday, 1 November 2024 01:35:35 UTC