-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support OPTIONS in routes #387
Comments
This would also need to be baked into the resource template stuff. |
Here's a canned-response preflight function just to show what might be returned:
Any/all portions of this should be overridable. The methods should reflect what is configured in any matching route (this part is hard since we don't currently track this if the method does not match). |
I'm thinking that adding a boolean |
For |
preflightOptions, optionsAccessControl implemented. Route matching and non-route matching implemented. Renders data for options requests if preflightOptions enabled. Tests present for route matching. Need to write tests for overall HTTP OPTIONS requests.
This has now been integrated into the World Singles code base for more extensive QA internally. If no issues arise, I'll close this out and update the documentation. |
Seems to be working appropriately. Closing. |
added preflightsOptions = 'true', based on framework-one#387
Whilst you can add
"$OPTIONS*" = "/main/options"
and hand back a canned response for preflight checks, it would be much better to be able to enable this for all routes and actually return the allowed verbs specific to each route as well as be able to specify the headers / credentials stuff.The text was updated successfully, but these errors were encountered: