Re: Feedback on INHIBIT and RESTORE, please?

[Glenn Strauss <[e-mail]>]

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