Support lower case options.

[latisaron]

Issue

Addressing: #37 (comment)

Approach

Given that we want to ensure backward compatibility until the option Port is fully deprecated, we still accept the Port option, but we delete it at Rackup::Server initialization and set its value to :port.

In case a user, for whatever reason, chooses to pass both port and Port, port takes precedence.

I also changed the WEBrick initialization from using Port to using port.

I am also wondering:

1. Are we okay with doing this deletion tactic, or are we assuming that people use server.options[:Port] which will now fail, because we have deleted that? (I changed the tests to function with this new approach)
2. Perhaps this should also be done for Host ?
3. Should there some deprecation message be added when Port is deleted?

Tests

Modified tests and they're all passing now:

Please let me know what you think!

[ioquatix]

The challenge here is other gems that provide Rackup::Handler will depend on Port: at least until they are also updated.

https://github.com/puma/puma/blob/master/lib/rack/handler/puma.rb#L54-L58

The best short term option, IMHO, is to provide both :Port and :port. I know this is messy, but I suspect we need to do that for all options.

So my advice is:

• We should parse options to :port and :ssl_whatever.
• We should have a normalisation function that deals with legacy options (i.e. duplicates them basically) before providing them to the handler, e.g. both :port and :Port are given.

Eventually, in a major version bump, we could deprecate the old options.

[latisaron]

* We should have a normalisation function that deals with legacy options (i.e. duplicates them basically) before providing them to the handler, e.g. both `:port` and `:Port` are given.

Eventually, in a major version bump, we could deprecate the old options.

What if the developer passes both port and Port, which you think should have priority?

[ioquatix]

I think priority should be given to the new options.

[latisaron]

HI @ioquatix .

I added another PR, where my approach was more or less what you proposed, with a few tweaks that I found while tinkering at it:

1. All parsing goes is done in the snakecase manner.
2. The normalization function duplicates keys in a redundant manner:

• It snakeifies the key SSLEnable -> ssl_enable
• It camelizes the snakeified key ssl_enable SslEnable
• It sets values for camelized, snakeified and raw key with a priority of snake -> camel -> raw

So, as the tests imply:

{:SSLEnable => true, :SslEnable => false, :ssl_enable => nil} => {:SSLEnable => nil, :SslEnable => nil, :ssl_enable => nil}

I am aware this adds a lot of redundancy, and does not solve issues like pOrt or sSlEnable, but those edge cases are solved by the priority with raw being last. If anyone specifically uses pOrt, they'll still find pOrt as a value.

If you agree with this approach I can optimise it a bit to avoid redundant assignments and such, given that currently it rechecks the values multiple times.

[Later Edit] The more I think about this, the uglier it seems, adding all those redundant values in the options, but I can't see a way around allowing custom values like "SomeTestValue" which anyone might want to use for their own implementation.

[latisaron]

I added some tests as well, and also ran the previous suite:

[latisaron]

@ioquatix I think one of the main issue of the above approach is that it tries dealing with both default rackup options and server options.

What do you think about moving the logic in a separate file which defines a constant set of 'predefined' possible option values which get normalized in a specific manner (SSLEncryption => ssl_encryption) and the remainder of options remain the same?