capitalization issues about cors_plug HOT 13 CLOSED

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.