I would like to know whether it is possible to get the headers from a plug as they where originally sent.
I know, that the headers in conn are all downcased by default:
req_headers - the request headers as a list, example: [{“content-type”, “text/plain”}]. Note all headers will be downcased.
but nevertheless I would like to get the original headers, not the manipulated ones. Is this possible? If not I would like to know what the reason for the downcasing is. I know, that headers are case insensitive, but that is not the same as downcasing these headers.
and I have the same question concerning response headers:
resp_headers - the response headers as a list of tuples, by default cache-control is set to “max-age=0, private, must-revalidate”. Note, response headers are expected to have lower-case keys.
I looks like, you can write beautiful code but only ugly headers with elixir.
content-type and Content-Type are the same HTTP-Headers, and since one want to be able to reliably match on them, one needs to normalize, this is done via downcasing in virtually every HTTP-library I have worked with across languages.
Also I do not see one were uglier than the other. HTTP Headers are read by machines, not humans, and machines do not have a sense of uglyness (at least I hope so).
whether headers needs to be normalized depends on the language. if the language supports the fact that “Content-Type” and “content-type” are the same, there is no need for normalization.
And virtually every http lib I worked with preserved the case from the request headers and let me have the freedom to set the case in the response header.
the the question remains: is there a possibility the get the original headers including the casing in the plug interface?
With plug/phoenix cowboy is the one which actually downcases the header keys (not the values, the values should remain the same). So, as long as you are using cowboy I am not sure if you can get the original header names.
If we take a step back, why do you want to get the header keys with their original case?
when there is no way, to get the original headers, we will have to refactor some services later in the pipe. but we have already decided to do this. getting the original headers would have simply been be a quick fix.
thanks for the pointer, minhajuddin, that there is no easy way around this.
What were you trying to accomplish? Getting the original headers seems entirely useless when following the spec, but if you have a specific reason then we may know of a work-around for that specific reason that would not necessitate getting that information?
As I understand him he has some clients that do NOT follow the spec, and exactly thats the problem.
I had to deal with an HTTP-server that didn’t either, and I had to virtually re-implement/wrap gos complete net/http-package from their stdlib because of that. It hasn’t been casing though, but the fact that that server expected headers in a certain order…
