Hi Stuart.

Stuart Henderson <stu.li...@spacehopper.org> wrote:
> On 2024-04-10, a...@abiscuola.com <a...@abiscuola.com> 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

Reply via email to