Don't allow trailing newlines in various checks.

[benpickles]

There's a subtle difference between what \Z and \z consider the "end of string" which is that the uppercase version allows a single trailing newline:

/\Afoo\Z/.match("foo\n")
# => #<MatchData "foo">

/\Afoo\Z/.match("foo\n\n")
# => nil

/\Afoo\z/.match("foo\n")
# => nil

The current usage of \Z / \z in the project can be discovered with:

$ git grep -iI "\\\z"

I've left the Cucumber steps alone as changing them makes adding the has_attached_file line fail.

[houndci-bot]

Use 2 spaces for indentation in an array, relative to the start of the line where the left square bracket is.

[tute]

Thanks! Why do we not want to allow for the new line character? Can there be a situation in which the headers do come with that character, and we don't process them properly after this change?

[tute]

ping @benpickles. Thanks!

[benpickles]

Sorry! This totally slipped my mind.

Yes you're right that's where the risk lies in this pull request - though no tests fail and I haven't encountered any issues. I haven't exhaustively confirmed all the code paths that spit out mine types (in fact I haven't investigated any :p) but I think I'm right in saying that the change that could cause unexpected consequences is in the validation suggested to users in the README and not in the library itself - no wait, here's one.

Either way the rest of the changes are probably what was originally intended in that a subdomain or file path cannot include newlines - so this could prevent potentially difficult-to-debug user error (though I imagine nobody has ever encountered this!).

[tute]

Thanks!