15
Two headers with the same name but one in upper case and the other in lower case, by default, are considered the same?
What HTTP does, unite them, ignore some or send both?
An application that waits for, for example, a header Authorization, but gets a header authorization must process using it or return an error?
There is a nomenclature pattern defined by some RFC?
13
They are case-insensitive. This is defined in RFC 7230, more specifically in the section 3.2 Header Fields.
This is one of the current Rfcs that specify the HTTP 1.1 standard. This set of Rfcs render obsolete the RFC 2616 which was used on the basis of that reply earlier (thank you, @Anderson Carlos Woss) - fortunately, there have been no significant changes in the part we have seen.
See the excerpt that talks about (my emphasis):
[...] Each header field consists of a case-insensitive field name Followed by a Colon (":"), optional Leading whitespace, the field value, and optional trailing whitespace.
So, trying to answer your questions:
Two headers with the same name but one in upper case and the other in lower case, by default, are considered the same?
Yes, they should be considered the same header, since the specification says that the fields are case-insensitive
What HTTP does, unite them, ignore some or send both?
HTTP does nothing at all. Who does it are the applications that follow it (browsers and web servers). And there is no way to give a canonical answer, because it really depends on implementation.
It is important to note that the specification (still in section 4.2) allows duplicate headers in cases where the header value accepts a comma-separated list of values, but this is the only case where this can be accepted.
See what the RFC says (again, emphasis for me):
Multiple message-header Fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)].
An application that expects, for example, an Authorization header but receives an Authorization header should process using it or return an error?
I think it’s already implied that you should process it. At least that’s what the specification says. No one can force you to implement this, so if you want to build an application that only processes headers that are on Camelcasing, you can do it. It won’t be within the HTTP specifications, but if you can live with it, fine =)
There is a nomenclature pattern defined by some RFC?
Is talked about Casing, the answer is no, because this should be ignored =D. There is not much to "standardize", agree?
In general, there must be some efforts to not let everything turn into a big mess, as is the case of RFC 6648 that talks about the prefix X-.
In the RFC 7231, section 5 is specifically spoken about HTTP headers, maybe it’s a good reading tip for you.
5
No. HTTP headers are not case sensitive. Here in reference HTTP/1.1 in section 4.2 you are saying this.
HTTP header Fields, which include general-header (Section 4.5), request-header (Section 5.3), re-sponse-header (Section 6.2), and Entity-header (Section 7.1) Fields, follow the same Generic format as that Given in Section 3.1 of RFC 822 [9]. Each header field consists of a name Followed by a Colon (":") and the field value. Field Names are case-insensitive.
Two headers with the same name but one in upper case and the other in lower case, by default, are considered the same?
Yes, they will be considered the same.
What HTTP does, unite them, ignore some or send both?
Use headers with the same name, even if they are case-sensitives, will cause problems on the platform that handles incoming headers. It depends on where it will be used, and it is not good practice to do this.
An application that expects, for example, an Authorization header but receives an Authorization header should process using it or return an error?
According to the RFC, it should consider both the same thing, be it the Authorization, authorization and AUTHORIZATION. Both should not be declared at the same time.
There is a nomenclature pattern defined by some RFC?
In June 2012, a recommendation was do not use X- at the beginning of the headers. Source.
3. Recommendations for Creators of New Parameters
...
SHOULD NOT prefix their Parameter Names with "X-" or similar constructs.
4. Recommendations for Protocol Designers
...
SHOULD NOT prohibit Parameters with an "X-" prefix or similar constructs from being Registered.
MUST NOT stipulate that a Parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.
MUST NOT stipulate that a Parameter without an "X-" prefix or similar constructs needs to be understood as standardized.
Sources:
Just be aware by using RFC 2616 as a base; it has become obsolete after the Rfcs 7230, 7231, 7232, 7233, 7234 and 7235.
Thanks for the remark, @Andersoncarloswoss.
Browser other questions tagged http http-headers cash-sensitivity
You are not signed in. Login or sign up in order to post.
Just be aware by using RFC 2616 as a base; it has become obsolete after the Rfcs 7230, 7231, 7232, 7233, 7234 and 7235.
– Woss
@Andersoncarloswoss Thank you very much. I got a glimpse in the header (pardon the pun) of 2616, but I had to leave. I adapted the answer, fortunately there were no significant changes in what we speak here.
– Jéf Bueno