Comments (13)
Sorry to hear that. But I’m afraid I don’t have a solution.
The Plug.Conn documentation is pretty clear about it expecting headers to be lowercase (and it will even raise if you try to put in uppercase header):
It is recommended for header keys to be in lower-case, to avoid sending duplicate keys in a request. As a convenience, this is validated during testing which raises a Plug.Conn.InvalidHeaderError if the header key is not lowercase.
Only think I can think of is writing a custom adapter the uppercase headers before sending the response although I was under the impression that the default cowboy adapter already does that.
from cors_plug.
Hey @macbem. Your comment does not provide additional information on this issue and uses offensive language ("which is kinda lame"). If you have a suggestion on how to fix this while staying compliant with the suggestions in Plug.Conn I would be super happy to implement them. Otherwise I'd suggest you adjust your language to the fact that you are using free software.
BTW: I am using my Plug in projects serving millions of people monthy. I therefore respectfully disagree with your assasment, that it is unusuable in the real world.
Please understand this as friendly advise, not as me trying to offend you. Thanks
from cors_plug.
@josevalim do you have suggestions for this particular case in which browsers expect upper-case headers but Plug.Conn prefers lower-case?
from cors_plug.
Which kind of issues have you seen? Can you provide more information? The HTTP spec declares headers are case insensitive.
from cors_plug.
Hey @josevalim thanks for your help! Per the reports above it sounds like some browsers are complaining. @issac-rstor, can you provide a browser including version that takes issue in non-capitalized headers, please?
from cors_plug.
@mschae I didn't mean it like that - sorry if I offended you in any way. I've removed my comment to avoid misunderstandings.
I've noticed that the issue is not really about uppercase / lowercase in my situation - what caused CORS-related headers to be rejected was the following:
- I triggered a request that had an error response, for example a 403
- first, there was an
OPTIONS
request - I got proper CORS headers in the response - then, there was a
POST
request, which generated an error and my fallback handler responded - this time, without CORS headers
Is it possible that fallback handlers somehow bypass the whole plug flow?
from cors_plug.
@macbem thanks for your reply, I didn’t take you initial comment personally.
I know how frustrating it can be to have the browser tell you there’s a CORS issue when it’s really a 500. Short of adding the headers in your error plug I’m not sure I know of a solution for that. As far as I know data added by plugs to the conn struct is not automatically returned when the pipeline fails. I’ve definitely seen what you describe myself.
As far as I recall all plugs (and that includes your controller method or last plug) are executed in the same context, so if one fails all fail.
So I’m afraid you’re either left with adding the headers manually in you error handler or accepting that 500 errors will result in cors errors.
from cors_plug.
@mschae it was not a 500 error, just a regular 40x, but it probably doesn't make any difference.
from cors_plug.
I believe that the version I was using is:
Chromium, Version 69.0.3497.81 (Official Build) Built on Ubuntu
I will attempt to do a repro of the effect later this week.
from cors_plug.
Is this still an issue?
@isaac-rstor Did you manage to Repo.
Many servers work with lowercase headers, because even though the HTTP/1 spec is case insensitive. The HTTP/2 spec insists that they are lowercase.
https://tools.ietf.org/html/rfc7540#section-8.1.2
Just as in HTTP/1.x, header field names are strings of ASCII
characters that are compared in a case-insensitive fashion. However,
header field names MUST be converted to lowercase prior to their
encoding in HTTP/2. A request or response containing uppercase
header field names MUST be treated as malformed (Section 8.1.2.6).
@macbem The 403 vs 500 error probably does make a difference, in what code handles creating the response. However in both cases the code that handles the response should respect response headers that have already been set. If cors_plug is setting them and they are not returned the issue will lie with the authorization_plug/error_handler that built the final response.
NOTE, if you have an authentication plug before the cors plug in the pipeline then the cors headers will never be set. but assuming they are in the right order then it is an issue in these other components
from cors_plug.
@CrowdHailer I joined another company, so I don't have access to the codebase that was experiencing those problems - I can't help you here.
from cors_plug.
@macbem Never mind.
I think this issue can probably be closed.
Unless there is a reproduction of the issue we can look at
from cors_plug.
it's hard to explain "steps to reproduce" because it depends on the browser. In any case, internally I solved this by forking the library with the option, and internally for me it REALLY doesn't matter since now we don't even have a cors issue since I serve the API with the backend using nginx routes now 😅
from cors_plug.
Related Issues (20)
- Support wildcard subdomains HOT 2
- Origin validation on OPTIONS HOT 3
- No CORS headers embedded in Plug.ErrorHandler code path HOT 2
- General CORS library HOT 3
- Options Requests without `Access-Control-Request-Method` should not be halted
- Unreachable code? HOT 2
- Support Plug 1.7 dependency HOT 1
- "Access-Control-Allow-Origin" is null when using regex for origin? HOT 3
- Configuration not working with Elixir 1.9 releases HOT 3
- Regex from string HOT 1
- FunctionClauseError when origin option is a list containing a regex HOT 1
- Regex isn't working on preflight request HOT 5
- A way to enable logging - difficult to configure HOT 3
- CORS Header empty HOT 2
- Looks like init function is called during the compile time HOT 1
- Access-Control-Allow-Credentials should not be included if set to false
- Headers cannot be set dynamically
- Minor security issue with origin checks
- Using config.ex does not work HOT 1
- default config of origin: * and credentials: true seems invalid?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cors_plug.