Case sensitive header lines

[ghost]

For example:

Content-Type: application/json

does not match

content-type: application/json

[JackuB]

Bump To elaborate:

I'm setting

### Exchange credentials for token [POST]
+ Request (application/json; charset=utf-8)
    + Headers

            Authorization: Basic ABCDEF

and then in my hook I have:

transaction.request.headers.authorization = header;

which results in:

headers:
    Content-Type: application/json; charset=utf-8
    Authorization: Basic ABCDEF
    User-Agent: Dredd/1.0.6 (Darwin 15.3.0; x64)
    authorization: Some other header
    Content-Length: 42

RFC2616 specifies that header names should be case-insensitive

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

[netmilk]

@JackuB Thanks for reporting this! I'm afraid this issue is not connected with the original one. The original issue was pointing out possible problem in validation of the real HTTP response to expected HTTP response given in the blueprint.

I'm afraid in this case the RFC you're referencing to isn't relevant. In the example you've given you're manipulating a javascript object representing the HTTP request you're going to send over the wire with a javascript code.

In my opinion, if you'd like to set securely a value of some header even though it has been already defined to be sure it won't be sent twice you should access the object some case-insensitive way.

This points out another problem of current design of the request and expected response object. Dredd doesn't support using one header twice although you could want / need it. And you actually came up with a workaround solution for that :) Good job! Let's track it here #412

[honzajavorek]

Just to make possible readers sure this is rightfully closed issue, couple of weeks ago I spent some time to verify that we handle HTTP headers in case-insensitive way in Apiary Documentation Console, Apiary Inspector Page, Dredd, Gavel.js. We do treat them correctly everywhere. Hence the problem why the original issue was opened and the problem @netmilk mentions in

possible problem in validation of the real HTTP response to expected HTTP response given in the blueprint

isn't present for some time already. I didn't notice there was an open issue for this, otherwise I'd close it at the time I performed the verification.