`before_handler` on middlewares not called for `OPTIONS` requests

[CircuitCoder]

before_handler seems to not be invoked during OPTIONS requests.

We're upgrading from an very old version of crow (>6 years old) which was before CORSHandler came into existence, so we had to handle CORS headers ourselves. We did this by adding these headers in the before_handler, which is not effective after the upgrade.

I'm reading crow's code, but haven't been able to find out what caused this behavior. Is this the intended behavior?

Thank you.

[Sightem]

Quite late for this reply, but quoting https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#preflighted_requests,

Unlike simple requests, for "preflighted" requests the browser first sends an HTTP request using the OPTIONS method to the resource on the other origin, in order to determine if the actual request is safe to send. Such cross-origin requests are preflighted since they may have implications for user data.

since the CORSHandler middleware is specifically designed to intercept these preflight requests, check them against its configured rules like allowed origins, methods, and headers and respond immediately with the appropriate Access-Control-* headers it renders having a manual before handler obsolete

[CircuitCoder]

Thank you for the answer!

Reading CORSHandler's source code, it seems that it also depends on after_handler. So is this particular behavior intended, that before_handler is not called for OPTIONS (and maybe HEAD?) requests, but after_handler is called?

[Sightem]

Yes this is intended behavior. OPTIONS requests are processed early in crow's routing process to bypass the main application's handler logic and for the reasons I highlighted before. Though the after_handler must still run because the generated OPTIONS response often needs modification right before the request is sent to comply with spec.

take a look at

Crow/include/crow/http_connection.h

Line 217 in e8b1251

void complete_request()

after the middlewares have run, that function finalizes the response headers. it checks if standard headers have already been set (either by the initial OPTIONS logic or by a middleware). if they are missing, prepare_buffers adds them to ensure the response is compliant before its serialized and sent. it also calls the after_handle methods for all relevant middlewares in sequence. This is where CORSHandler::after_handle runs and adds the necessary headers to the response object.

HEAD requests are not treated the same though, they do execute the full middleware chain, obviously providing if a matching path exists. it first attempts to find a specific handler defined for the HEAD method, if none is found, it falls back to executing the corresponding GET handler for the same URL path, but sets an internal skip_body flag. In either case, because a valid route handler is identified, the before_handler runs, followed by the route handler itself (either the specific HEAD one or the fallback GET one).

take a look at

Crow/include/crow/http_response.h

Line 237 in e8b1251

void end()

[CircuitCoder]

Thank you for the answer!

I personally think this behavior is a little bit unintuitive. Do you think it's a good idea to mention it in the doc? I would be happy to do the PR.