Hi Stuart.
Stuart Henderson <[email protected]> wrote:
> On 2024-04-10, [email protected] <[email protected]> wrote:
> > Is there a way to restore the previous behaviour in relayd(8)
>
> Only by reverting the commit etc.
>
> > or, is there a known workaround for restic, in this case?
>
> That's probably a question for restic really (or possibly the
> requirement is coming from a 3rd party REST library).
>
> > I know that relayd(8) is right
>
> It seems a little strict to me.
Yes and no.
I mean, while I agree that it looks a bit too strict, the restic
developers are wrong assuming that *any* proxy, put between a
restic HTTP server (that might not even be the packaged
restic-rest-server) and the client would return the headers as
they expect and they are also wrong assuming that the content-length
will be the same between a HEAD call and a GET call.
They even told me that there is no reason why a proxy would mangle
the response headers. Probably they never had to deal with a setup
in a classic corporate network.
That said, IMHO relayd(8) should have shipped with an option, in the
configuration file, to restore the previous behaviour, while
keeping the new one the default.
>
> To my eye, the older version of the HTTP spec requires it ("The
> Content-Length entity-header field indicates the size of the
> entity-body, in decimal number of OCTETs, sent to the recipient or, in
> the case of the HEAD method, the size of the entity-body that would have
> been sent had the request been a GET").
>
> That's been replaced now but it's still permitted: "The server SHOULD
> send the same header fields in response to a HEAD request as it would
> have sent if the request had been a GET, except that the payload header
> fields (Section 3.3) MAY be omitted."
It's permitted, but not mandatory. This is, of course, on the client
program to fix properly.
Anyway. I worked around the problem by putting the restic server behind
a simple TCP relay in relayd(8). Of course, I also needed to change the
public port, but that's a minor nuisance.
Being able to keep the 443 would have been better.
--
absc
