Feature Request: Terminating preflight options requests

[sripberger]

When it comes to preflight OPTIONS requests, the only thing the browser really cares about is the access control headers. If we're making HAProxy responsible for handling all of these headers, it makes sense that it could also terminate the request, without needing to forward it through to an underlying api server.

This is something I know is possible with NGINX but I'm having a hard time finding information about how to do it with HAProxy. It would be nice if this library had some way of handling it, though barring that, some assistance in scripting it myself-- or even insight into whether or not this kind of thing is even possible with HAProxy-- would be super helpful.

Thanks ahead of time.

[NickMRamirez]

I would like to see this too: HAProxy should intercept the request and if it is an OPTIONS, it should return an immediate response without forwarding the message to the backend server.

However, it's not currently possible using Lua in HAProxy. What I have found is that you can either create an "action", which can operate on a request coming in or on a response going out, but it can't intercept-and-return. Or, you can create an "applet", which intercepts a request and returns a response, but it can never forward to the backend server.

It would be nice to mix the two, but I have not found this to be possible with the current Lua integration. This library could create an applet and an action, but it would be more complicated to use in the HAProxy configuration.

Some links:

• Blog post about the different things you can create with Lua in HAProxy
• Lua / HAProxy documentation

[aleskiontherun]

Hey guys, I stumbled upon this thread trying to figure out the same thing. Ended up fixing it with a simple service returning an empty response. See #9

[NickMRamirez]

The applet doesn't return the correct header, though.

There's a new feature coming in HAProxy 2.2 that allows HAProxy to return a response directly that might solve this problem. http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#http-request%20return

[NickMRamirez]

I've come up with an alternate approach, which does not require using use-service to return an empty reply for OPTIONS requests. However, it requires HAProxy 2.2. In that version, a new class called Reply was added, which lets you return a reply from a Lua action. So, the haproxy.cfg becomes:

listen api
    bind :8080

    # Invoke the CORS service on the request to capture the Origin header
    http-request lua.cors "GET,PUT,POST", "localhost"

    # Invoke the CORS service on the response to add CORS headers
    http-response lua.cors
    server s1 server1:80 check

...where the allowed methods and allowed origins are set only on the http-request line and that line will also reply to OPTIONS requests without forwarding them to the backend servers.

I've put this into a branch for now: https://github.com/haproxytech/haproxy-lua-cors/blob/preflight_reply/lib/cors.lua. Since this won't work for versions older than 2.2, I think there would need to be a tagged release.