Use Rack's Constants #2435
Merged
Use Rack's Constants #2435
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use Grape and Rack header constant in specs Drop self.lowercase? and rack2 integration since we're using Grape::Util::Header Change rack_3_0' integration tests to make sure we are returning lowercase headers
Add CHANGELOG entry
ericproulx
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Since we dropped support for rack 1.X, we can replace some of our constants by Rack's constants. For instance, we had defined all supported http methods like
Grape::Http::Headers::GET,Grape::Http::Headers::POSTetc... but its already defined asRack::GET,Rack::POST, etc... in Rack.We also had redefined some Rack's constants in our code base like
Grape::Env::RACK_INPUT,Grape::Env::RACK_REQUEST_FORM_HASHetc ... but these are Rack's internals and we should not rely on them and use Rack's constantsRack::INPUT,Rack::REQUEST_FORM_HASH.At least, if Rack as major internal changes, Grape's will be in line with these changes even if it's a renaming or a drop. In the end, Grape is rack based and it all makes sense to do that since we were already using several Rack's utility functions.
Although, Grape should have a smaller memory footprint since we have less string literals.
Finally, I've changed Rack 3.0's integrations tests to make sure all our response headers are lowercased instead of looking if our internal headers are in lowercase. If makes more sense with #2425.
Thanks