Support headers in ALL_CAPS_WITH_UNDERSCORES

[jellybob]

In investigating #86 I encountered a second issue, whereby any headers after one we send which is in caps with underscores were being dropped.

Firstly, I know its not really compliant with de-facto HTTP standards, where all headers are capitalised with dashes between them, but it is a thing that exists and I can't find anything in the HTTP standard which explicitly says it isn't supported.

I'm quite happy to resolve this issue myself if you can give a pointer to either the right place (in which case I'll submit a PR), or the HTTP standard that says it shouldn't be supported (in which case I'll go away and fix our code).

[jellybob]

Looking at this further, I'd argue that if a header can't be parsed it should either cause a response indicating that occurred, or the header should be ignored. The HTTP spec while not entirely clear on header naming standards, is very clear that the boundary between headers and body is a line containing only \n or \r\n.

[ioquatix]

Can you submit a failing test case? (e.g. a spec that fails)

[ioquatix]

Maybe it should go into protocol-http1.

[jellybob]

This Sinatra application shows the behaviour described:

# frozen_string_literal: true

require 'sinatra/base'

# The app
class MyApp < Sinatra::Base
  get '/' do
    headers.inspect
  end
end

use MyApp
run ->(_env) { [404, {}, []] }

When I use a telnet session to send the following request I immediately get a response on sending the capitalised header:

$ telnet 127.0.0.1 9292
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Foo: Bar
Test-Header: Test
CAPITALISED_HEADER: Test
HTTP/1.1 200 OK
content-type: text/html;charset=utf-8
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
content-length: 21

{"Content-Type"=>nil}

[ioquatix]

This should be working with the latest release, can you please check?

[ioquatix]

I have confirmed this is now working.