Options * example not working

[pfk84]

I tried the example of returning an OPTIONS response to * but I couldn't get it to work, I always just get a 405 response...

// OPTIONS *
$app->options('', function () {
    return new React\Http\Message\Response(200);
});

[clue]

@pfk84 This is an interesting one, thanks for bringing this up!

The OPTIONS * request is supported just fine by X and is covered both by unit tests and additional integration tests. In particular, this is also verified on different web servers as part of our CI setup:

framework-x/tests/acceptance.sh

Line 103 in 12fb355

out=$(curl -v $base -X OPTIONS --request-target "*" 2>&1); skipif "Server: nginx" && match "HTTP/.* 200" # skip nginx (400)

To the best of my knowledge, this works just fine across different web servers. Only nginx is known to reject OPTIONS * requests with a 400 Bad Request response, so these requests would never even end up being passed to X. See also the above test cases and https://stackoverflow.com/questions/14929347/how-to-handle-options-request-in-nginx for possible work-arounds.

I hope this helps 👍 If the problem persists, can you give more detailed instructions on how to reproduce the problem you're seeing?

(Refs #46)

[pfk84]

Ah ok, I somehow assumed that would mean that X returns on every URI but it makes sense that this is for the special case of "whole server".

Is there any way that X returns the supported options for the defined routes automatically?
Like if I have defined $app->get('/users') and $app->post('/users') an OPTIONS requests returns Allow: GET, POST, OPTIONS

But then again there's more like Alow-Headers & -Origin... Seems like there's need for a dedicated Middleware... :)

[clue]

Is there any way that X returns the supported options for the defined routes automatically? Like if I have defined $app->get('/users') and $app->post('/users') an OPTIONS requests returns Allow: GET, POST, OPTIONS

But then again there's more like Alow-Headers & -Origin... Seems like there's need for a dedicated Middleware... :)

Sounds like an interesting suggestion indeed! If you're using an unregistered HTTP request method, X already answers with a 405 Method Not Allowed HTTP response indicating all valid HTTP request methods in the Allow HTTP response header (see #37), but I'm not opposed to also expose this to the API layer somehow 👍 Perhaps bring this up as a separate ticket to discuss this in more detail?

[pfk84]

FYI: If X is used to build an API that is accessed via XHR an OPTIONS request is issued by the browsers before the actual request which X then rejects with 405 Method Not Allowed leading the call to fail/never even be sent.

One solution is to register a dedicated ->options route to each and every route (ugh...) or as I did create/use a CORS middleware that does this automatically. So if X could do this without a middleware or would ship with one, I think this would be a welcomed addition.

[clue]

@pfk84 Sounds like a good suggestion, perhaps you can file a separate discussion ticket to discuss this in more detail? 👍