RFC | Title | Author | Status | Type |
---|---|---|---|---|
90 |
Server HTTP HEAD |
Jeremy Miller <jmiller@chef.io> |
Accepted |
Standards Track |
There is a greater resource cost than is necessary when querying the Server
API named object endpoints for the existence of a single object. Currently, if
checking for an object's existence, only HTTP GET
requests are supported by
the server. This means the entire object is fetched, consuming resources
across the server, network and client. When viewed from a large scale
perspective, this overhead can cause slow downs that can have compounding
effects.
As a Chef developer,
I want to be able to write code that queries the
Server for the existence of a single object via a light-weight API call
and response,
so that my applications can run as efficiently and as
quickly as possible.
The HEAD method shall be identical to GET except that the server must not return a message-body in the response.
The meta-information contained in the HTTP headers in response to a HEAD request should be identical to the information sent in response to a GET request.
The HEAD HTTP verb will be added to oc_erchef and chef-zero named object
endpoints such that a client http HEAD request for an object name will result
in the following standard http response codes (no different than a GET
):
Code | Reason |
---|---|
200 | object exists |
401 | request signature is invalid |
403 | requestor does not have READ on the object |
404 | object does not exist |
example named endpoint: /nodes/NAME
In addition to chef-server
, chef-zero
will need this capability added so
that it remains in lock-step.
As an optimization and/or feature addition, several other downstream items could benefit including: Chef::ChefFS, Chef::Knife, knife-ec-backup.
This work is in the public domain. In jurisdictions that do not allow for this, this work is available under CC0. To the extent possible under law, the person who associated CC0 with this work has waived all copyright and related or neighboring rights to this work.