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> > > In practice, what I'm struggling with is the: > > > > * ability to control the requests or responses by HTTP method, i.e. > > only allowing GET by default and access controlling POST and PUT > > It turned out that filtering the requests per method was possible > at least as follows: > > match request method "GET" tag "REQ_OK" > block request > pass tagged "REQ_OK" > > $ curl -i -X GET https://www.huttu.net > HTTP/1.1 200 OK > > $ curl -i -X POST https://www.huttu.net > HTTP/1.0 403 Forbidden > Date: Sat, 07 Nov 2020 14:53:20 GMT > Server: OpenBSD relayd > Connection: close > Content-Type: text/html > Content-Length: 427 > > 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. > > > * 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" > Best regards, > > Lari Huttunen > -- > "See the unseen." > --
