- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Tue, 5 Mar 2024 04:17:54 -0500
- To: Eric J Bowman <mellowmutt@zoho.com>
- Cc: Ietf Http Wg <ietf-http-wg@w3.org>
On Mon, Mar 04, 2024 at 11:10:00PM -0800, Eric J Bowman wrote: > INHIBIT and RESTORE Methods for HTTP > > Abstract > > Temporarily changing the availability status of a resource, is a common procedure in webserver administration. It is typically accomplished by editing a configuration file, or overloading the POST method by using it to affect changes which fall outside the scope of altering the content of, or creating, a resource. HTTP additionally attaches creation and destruction semantics to PUT and DELETE. This proposal suggests two new HTTP methods, INHIBIT and RESTORE, as a mechanism for clarifying server behavior for intermediaries, and in log files. First impressions (and not well-formulated): ISTM that you want the origin server to implement a policy layer, but stored in/near/with a resource. Just as authentication and authorization are often server configuration rather than attributes or properties of a resource, so too are INHIBIT and RESTORE. Just as with WebDAV properties, certain properties may be attached to a resource, such as owner information and ACLs, but the origin server must check these properties and act on them. Should such properties be served to the end user? The ACLs list is not generally served to an unprivileged user. Similarly, INHIBIT and RESTORE likely are also privileged commands which should require authentication and authorization. Overall, this implementation of the INHIBIT and RESTORE policy seems to me to be something that is an admin control panel which handles some sorts of requests (POST request to inhibit, POST request to restore), but not something which needs to be separate methods at the HTTP layer. POST /cgi-bin/admin-control?method=inhibit&target=/url/to/resource (e.g. similar to an example you described in the Abstract) Instead of knowing the /cgi-bin/admin-control panel URI, it seems as if you want a meta-layer in requests to invoke the admin-control panel application to handle the request instead of the origin server handling the request natively. Is this extending WebDAV? Or is this building an admin control panel into the HTTP layer? Inhibiting a resource to always return 503 is a server configuration policy, not wholly a property of the resource, even if a randomly-named property could be added to a resource and the server configuration could check for and act on said property. Why should INHIBIT and RESTORE be separate methods at the HTTP layer? (Honest question) You mentioned that PUT and DELETE operate directly on the resource, and they operate on the resource content. I hear that you are suggesting that INHIBIT temporarily be an alternate response (not actually resource content!). That is not a modifying the resource per-say, but instead modifying the policy response to requests for the resource. (Please forgive me if I am not using the resource terminology correctly or precisely.) Why is the result of the INHIBIT command not something like HTTP/1.1 503 Service Unavailable Cache-Control: purge-all-your-variants # (fabricated) or HTTP/1.1 451 Unavailable For Legal Reasons Cache-Control: purge-all-your-variants # (fabricated) For the sake of being gross (don't do this), instead of using POST, I can overload the DELETE method with some headers, such as If-None-Match: * Inhibit-Policy: xxxxx for "temporary deletion" of the resource and If-None-Match: * overloaded to prevent the server from accidentally deleting the file but leveraging authentication and authorization to make sure I have DELETE access (as long as the server implemented If-None-Match and ETag for the resource, and special-cased Inhibit-Policy to change server configuration instead of 412 Precondition Failed because of If-None-Match: *). Again, apologies for the scatter-brained response. The ideas behind INHIBIT and RESTORE are interesting, but IMHO the policy implications and potential implementation details are far more complicated and would need to be fleshed out a bit for general guidance in an RFC. Your multipart request to provide the response content for 503 pages for different languages is a good example of this complexity. INHIBIT and RESTORE feel to me more an extension to WebDAV or new admin interfaces rather than base HTTP layer. Servers with those layers might be able to incrementally add INHIBIT-like and RESTORE-like properties to resources and implement policies based on those properties. Cheers, Glenn
Received on Tuesday, 5 March 2024 09:18:10 UTC