-
Notifications
You must be signed in to change notification settings - Fork 57
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
method '*' treated differently from others #241
Comments
If you provide a patch I'm happy to review it. |
I suspect it's a bug that aiohttp-cors works great for GET and throws a configuration error for method '*'. I don't see any tests for method '*' actually working. There are tests in tests/unit/test_cors_config related to webviews and mixins. That appears to be the only tests related to method '*'. aiohttp-graphl is an example of middleware that expects method='*' to work |
@wumpus sorry. |
Ping. I think the basic issue is:
|
Hi, @asvetlov ! |
Same problem here |
@andrii-maksymov and @jogc what middleware are you using? |
this is what i do, there is no other middleware used
|
Thanks @jogc so you're using exactly the same middleware that I am. Here is my patch that works around the problem in aiohttp_graphql, by handling every method other than OPTIONS: |
I'm trying to use aiohttp-cors with aiohttp-graphl, which registers a route with the '*' method. I get
ValueError: <PlainResource 'graphql' /graphql> already has a '*' handler for all methods
Here is a small reproducer showing that '*' is different:
which prints
Reading the aiohttp-cors code I can see that _is_web_view() is False and then causes this confusing message? But only for method '*' and not GET.
I hacked the aiohttp-cors code to create separate routes for all the methods other than OPTIONS, and my program now runs successfully. But obviously that's not a fix.
The text was updated successfully, but these errors were encountered: