| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
|
|
|
|
|
|
| |
It should not throw a NameError, but should throw a KeyError.
Fixes #26278
|
|
|
| |
When initializing an `ActionDispatch::Http::Headers` object it takes a request object (Rails 5) whereas before it took a hash (Rails 4.x) but the documented example still shows a hash given to the constructor (due to commit 34fa6658dd1b779b21e586f01ee64c6f59ca1537) so this is just a documentation change to use the new `from_hash` method introduced in that earlier commit.
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue #16519 covers confusion potentially caused by how HTTP
headers, that contain underscores in their names, are retrieved
through `ActionDispatch::Http::Headers#[]`.
This confusion has its origin in how a CGI maps HTTP header names
to variable names. Even though underscores in header names
are rarely encountered, they are valid according to RFC822 [1].
Nonetheless CGI like variable names, as requested by the Rack
specfication, will only contain underscores and therefore the
original header name cannot be recovered after the Rack server passed
on the environemnt hash. Please, see also the disscussion on
StackOverflow [2], which also links to an explaination in the
nginx documentation [3].
[1] http://www.ietf.org/rfc/rfc822.txt
[2] http://stackoverflow.com/questions/22856136/why-underscores-are-forbidden-in-http-header-names
[3] https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#missing-disappearing-http-headers
|
|
|
|
|
|
|
| |
* Introduce `ActionDispatch::Http::Headers#add` to add a value to
a multivalued header.
* Move `Response#add_header` upstream: https://github.com/rack/rack/pull/957
* Match upstream `Response#have_header?` -> `#has_header?` name change.
|
|
|
|
|
|
| |
Just include the modules necessary in the Request object to implement
the things we need. This should make it easier to build delegate
request objects because the API is smaller
|
|
|
|
| |
Now the Headers internals don't depend on the env hash.
|
|
|
|
|
| |
This prevents external mutations from impacting the internals of the
request or the Header object.
|
|
|
|
|
| |
this reduces the API footprint for the env hash so that we can be more
flexible when changing API in the future
|
|
|
|
| |
This allows us to avoid calling `env_name` twice.
|
|
|
|
| |
duping the request will dup it's underlying env hash.
|
| |
|
|
|
| |
Also expand the CGI_VARIABLE name listing to multiple lines for cleaner diffs and legibility.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if you were looking for a given key, the header may incorrectly tell you that it did not exist even though it would return a valid value:
```ruby
env = { "CONTENT_TYPE" => "text/plain" }
headers = ActionDispatch::Http::Headers.new(env)
headers["Content-Type"]
# => "text/plain"
headers.key?("Content-Type")
# => false
```
This PR fixes that behavior by converting the key before checking for presence
|
|
|
|
|
|
|
|
|
| |
The env hash passed to `Http::Headers#new` must be in env format.
Also be aware that the passed hash is modified directly.
docs and test-cases for setting headers/env in functional tests.
Follow up to #9700.
|
| |
|
|
|
|
| |
Closes #6513.
|
|
|
|
|
| |
Also:
cleanup, use consistent syntax for `Http::Header` and test.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|