On Sun, 30 Jun 2024 14:42:03 +0100,
Stuart Henderson <stu@spacehopper.org> wrote:
> 
> On 2024/06/29 19:16, Christopher Zimmermann wrote:
> > Hi,
> > 
> > responses to HEAD requests SHOULD return the same headers a GET request
> > would yield (https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.2).
> > 
> > Therefore the Content-Length header should not be stripped from responses to
> > HEAD requests.
> > 
> > This bit me when relaying traffic between restic and a restic-rest-server.
> > Restic gets confused by the missing Content-Length: header and complains
> > about a "negative content length" when checking for the presence of /config.
> 
> There's also this, though:
> 
> "However, a server MAY omit header fields for which a value is
> determined only while generating the content"
> 
> and specifically goes on to talk about HEAD.
> 
> While I'm not sure what is the most appropriate thing for relayd
> to do here, it seems to me that restic should not rely on getting
> Content-Length in response to HEAD requests either.
> 

My two cents:

1. at the end of that paragrph you may see:

   Such a response to GET might contain Content-Length and Vary fields, for
   example, that are not generated within a HEAD response. These minor
   inconsistencies are considered preferable to generating and discarding the
   content for a HEAD request, since HEAD is usually requested for the sake of
   efficiency.

2. thus, the old RFC 2616 for HTTP/1.1 states:

   The HEAD method is identical to GET except that the server MUST NOT
   return a message-body in the response. The metainformation contained
   in the HTTP headers in response to a HEAD request SHOULD be identical
   to the information sent in response to a GET request. This method can
   be used for obtaining metainformation about the entity implied by the
   request without transferring the entity-body itself. This method is
   often used for testing hypertext links for validity, accessibility,
   and recent modification.

what I read as for better comtability better to keep that header.

-- 
wbr, Kirill