- From: Karol Szczepański via GitHub <sysbot+gh@w3.org>
- Date: Sun, 16 Oct 2022 12:35:11 +0000
- To: public-hydra-logs@w3.org
>> If a hydra:Forbidden operation is executed by the client due to having stale metadata or whatever other reason, isn't it natural to think that the server would respond with a 403 Forbidden? Hmm, no, not really - it generally depends on what is stale - operation may not be there at all, or expected type could have been changed or many other situations might have been changed and `hydra:Forbidden` wouldn't give it all about them. I'm even more into replacing it with simple and straightforward `hydra:Unavailabble`. >> Exactly. So if a client inadvertently executes an operation currently marked as hydra:Unauthorized, the server would respond with 401 Unauthorized. Right? Yes, this might be the only place that fits one-to-one with HTTP. >> Client asks Server for its available operations. Some of Server's operations are delivered by upstream servers U1 and U2. To deliver a fresh list of available operations to the Client, Server asks U1 and U2 for their operations. U1 is currently unavailable and responds with HTTP 503 Service Unavailable. U2, however, is available and responds with its operations. This example does not talk to me at all. If the U1 operations are not available why broadcastim them in the first place? I think this is against initial idea of retracting operations. Presented terms were meant to retract something that has been broadcasted earlier, not to denote an operation as a placeholder for something that might be there in future. -- GitHub Notification of comment by alien-mcl Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/246#issuecomment-1279961029 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 16 October 2022 12:35:13 UTC