Re: Relayd Help Needed
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 +:
> > On Sat, Nov 07, 2020 at 08:29:12AM +, Lari Huttunen wrote:
> > > Cheers!
> >
> > 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 { $private }
table disable { $private }
# Check for 200 and then use a fallback that is routed to
# httpd.
forward to port 8080 check http "/" code 200
forward to 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."
Re: Relayd Help Needed
Lari Huttunen(open...@huttu.net) on 2020.11.07 15:01:04 +: > On Sat, Nov 07, 2020 at 08:29:12AM +, Lari Huttunen wrote: > > Cheers! > > > 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." > --
Re: Relayd Help Needed
On Sat, Nov 07, 2020 at 08:29:12AM +, Lari Huttunen wrote: > Cheers! > 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? > * 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? Best regards, Lari Huttunen -- "See the unseen."
Relayd Help Needed
Cheers! I wanted to try to learn more about relayd and use it as a reverse proxy in front httpd and a GO implementation called go_ipfs. The setup is as follows: * httpd is used for acme + http -> https redirects * go_ipfs is used to serve the static websites. I have the setup working quite ok for the most part and those curious can read my write-up here: https://www.huttu.net/posts/web/ All feedback, comments will be appreciated, since I'm not yet very well versed in the art of relayd. (A special shout-out to Aaron D. Parks, who had written a good how-to which helped me a lot in this task. https://parksdigital.com/httpd-and-relayd-on-openbsd.html) 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 * 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. I'm running OpenBSD 6.8 and am wondering if what I'm attempting to do is possible with the current version of relayd? Thanks in advance! Lari Huttunen -- "See the unseen."
