On Sat, Nov 07, 2020 at 09:56:29PM +0100, Sebastian Benoit wrote: > Lari Huttunen(open...@huttu.net) on 2020.11.07 15:01:04 +0000: > > On Sat, Nov 07, 2020 at 08:29:12AM +0000, Lari Huttunen wrote: > > > Cheers! > > <clip> > > The only downside is that for unknown request types I still get a > > 500 from relayd. For example: > > > > $ curl -i -X WHATNOT https://www.huttu.net > > HTTP/1.0 500 Internal Server Error > > Date: Sat, 07 Nov 2020 14:55:32 GMT > > Server: OpenBSD relayd > > Connection: close > > Content-Type: text/html > > Content-Length: 442 > > > > Is that the intended behavior? > > Yes, > > see relay_read_http() in relay_http.c. > > Unknown http methods reult in a 500 error.
OK, the way I read the HTTP specification, the more suitable responses might be either: 400 BAD Request: https://tools.ietf.org/html/rfc7231#section-6.5.1 The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing). 501 Not Implemented: https://tools.ietf.org/html/rfc7231#section-6.6.2 The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. A 501 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]). > > > * ability to control the behavior of relayd based on the response > > > code from the backend IPFS web server, e.g. upon a 404, redirecting to > > > generic 404 page on the httpd. > > > > So what remains missing is the ability to control the responses > > back to the client in a controlled manner. > > > > Does anyone have a recipe for this, please? > > You should be able to set a Location header on a response: > > match response header set "Location" value "https://something"; tagged "FOO" Unfortunately this does not work, or at least I was unable to make it work, as the matching above is tied to the response header, not the response code, which not a header, but a status-line. I did try a different approach in the relay section, but it failed in a different way as it does not seem to be intended for my use case: table <static-sites> { $private } table <fallback> disable { $private } # Check for 200 and then use a fallback that is routed to # httpd. forward to <static-sites> port 8080 check http "/" code 200 forward to <fallback> port 8081 It works as long as the front-end code results in 200 vs. 404. In reality, modern (static) web page response codes are more dynamic. I observed the following valid response codes in addition to 200, which broke my test setup above: 304 Not modified: https://tools.ietf.org/html/rfc7232#section-4.1 307 Temporary redirect: https://tools.ietf.org/html/rfc7231#section-6.4.7 204 No Content: https://tools.ietf.org/html/rfc7231#section-6.3.5 Is there a way to just catch the 404 responses from the backend instead of trying whitelist the valid responses? The way I understand it is that relayd is capable of altering the behavior based on the response headers, but not the response status-line, which precedes it. https://tools.ietf.org/html/rfc7230#section-3.1.2 Have I misunderstood something? Best regards, Lari Huttunen -- "See the unseen."
