-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add support for CORS in WebMessageHandler #106
base: master
Are you sure you want to change the base?
Conversation
The `Vary: Origin` is to secure caching if the returned data is different depending on the host making the request.
Dude awesome job! I really like the idea of using prepare to determine if the resource is CORS-able or not - but can you split that out into a separate decorator? My understanding is that prepare is really meant for subclasses to overwrite - I don't want to depend on functionality there. Also making it into a decorator allows people to explicitly mark which resources are for cors and which ones are not. Can you make origin, headers, methods, exposed headers, and allowed credentials properties, rather than methods? Keeping those static as much as possible should make things faster. What do you think about turning the part that handles credentials/allow-origin = * into a function so it's not duplicated? I could go either way on that one. Thoughts? |
Thanks for reviewing it! I was already pending towards defining it as a decorator, makes sense. Turning those methods into simple instance attributes is better. I think I'll override I thought about turning that snippet into a function, but since on runtime it's basically a condition check and an assignment, I thought a function call would be more overhead than repeating a little code. |
that's probably true that a function is more overhead. I think since they're static they should be class properties, rather than I think that will be faster/less overhead, and semantically I think it's On Tue, Feb 19, 2013 at 4:38 PM, Paul Eipper [email protected]:
|
Also this is so, so slick. I have a bunch of crappy patched @cors_support On Tue, Feb 19, 2013 at 4:50 PM, Ben Beecher [email protected] wrote:
|
I believe I addressed your points with these commits, although I didn't test the code thoroughly after the refactoring. |
Allow easy support for Cross-Origin Resource Sharing requests by
simply returning a list of hosts on the
cors_allow_origin
method.