| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This can still be added to the middleware stack, but is really not
necessary. I'll follow up with a commit that deprecates the constant
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
all parameter parsing is done on the request object now, so we don't
need to worry about at ParamParser middleware
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The test request object will handle parsing XML posts now, so we don't
need to eagerly parse them in the test harness
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The request object will automatically parse these in the
`parse_formatted_parameters` method, so we don't have to worry about it.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is an instance method on the request object now so we don't need it
anymore
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
we don't actually need a param parser middleware instance since the
request object will take care of parsing parameters for us. For now,
we'll just configure the parameter parsers on the request in this class.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The middleware stack is a singleton in the application (one instance is
shared for the entire application) which means that there was only one
opportunity to set the parameter parsers. Since there is only one set
of parameter parsers in an app, lets just configure them on the request
class (since that is where they are used).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Parameters will not be parsed until they are specifically requested via
the `request_parameters` method.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
we need to be more specific about exception handling when dealing with
the parse strategies. The calls to `return yield` can also raise an
exception, but we don't want to handle that in *this* code.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`normalize_encode_params` is common to all parser code paths, so we can
pull that up and always apply it before assigning the request parameters
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
since there is only one "default" strategy now, we can just use the
block parameter for that.
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | | |
All parameter parsing should be on the request object because the
request object is the object that we ask for parameters.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
this commit removes some direct access to `env`.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit is to abstract the code away from the env hash. It no
longer needs to have the routes key hard coded.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This changes the renderer class to store the controller and defaults as
an instance variable rather than allocating a new class. You can create
a new renderer with an new env by calling `Renderer#new` or use new
defaults by calling `Renderer#with_defaults` and saving the return value
somewhere.
Also I want to keep the `env` private since I would like to change the
keys in the future. This commit only translates particular keys that
the user requested.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
this means the reader doesn't need to lock, but does have the added cost
of a new object created for every controller
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The controller class is shared among threads, so we need to lock when
allocating the Renderer.
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Remove wrong doc line about AC::Parameters
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
AC::Parameters does not inherit from HashWithIndifferentAccess
since #20868 by @sikachu
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
`Rack::Session::Abstract::ID` is now deprecated and
`Rack::Session::Abstract::Persisted` should be used instead.
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In c546a2b this was changed to mimic how the browser behaves in a real
situation but left out types that were registered.
When this was changed it didn't take `text/plain` or `text/html` content
types into account. This is a problem if you're manipulating the
`Content-Type` headers in your controller tests, and expect a certain
result.
The reason I changed this to use `to_sym` is because if the
`Content-Type` is not registered then the symbol will not exist. If it's
one of the special types we handle that specifically (:json, :xml, or
:url_encoded_form). If it's any registered type we handle it by setting
the `path_parameters` and then the `request_parameters`. If the `to_sym`
returns nil an error will be thrown.
If the controller test sets a `Content-Type` on the request that `Content-Type`
should remain in the header and pass along the filename.
For example:
If a test sets a content type on a post
```
@request.headers['CONTENT_TYPE'] = 'text/plain'
post :create, params: { name: 'foo.txt' }
```
Then `foo.txt` should be in the `request_parameters` and params related
to the path should be in the `path_parameters` and the `Content-Type`
header should match the one set in the `@request`. When c546a2b was
committed `text/plain` and `text/html` types were throwing a "Unknown
Content-Type" error which is misleading and incorrect.
Note: this does not affect how this is handled in the browser, just how
the controller tests handle setting `Content-Type`.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This method is specifically about the content type so lets remove the
parameter.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
create a singleton content type that just has nils, so that we don't
have to allocate a content type object all the time.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If someone sets just a charset, but depends on the implicit type from
rendering, this will store a strange content type header that looks like
this: `; charset=blah`. This is so that when the content type header
is parsed again, it will return nil for the actual type.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It turns out that the response object never really cares what the mime
type object is, so just use the string.
|
| | | | |
| | | | |
| | | | |
| | | | | |
pull content-type setting to a private method to dry it up.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Instead of storing content type information in an ivar and a header,
lets move to just store the content type info in just the header.
|
| | | | |
| | | | |
| | | | |
| | | | | |
we'll use this method later to lazily parse content type headers.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
everything above metal really doesn't care about setting the content
type, so lets rearrange these methods to be in metal.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
_set_content_type only does something when there is a request object,
otherwise the return value of _get_content_type is always ignored. This
commit moves everything to the module that has access to the request
object so we'll never to_s unless there is a reason
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
in the future I would like to make the header hash read only (or at
least remove guarantees that mutations will do anything).
|
| | | | |
| | | | |
| | | | |
| | | | | |
It's only used there.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`CookieJar` is only at the start of the chain and has its own
request method, so we don't need it in the module.
|
| | | | |
| | | | |
| | | | |
| | | | | |
It was the same in both legacy versions of the signed and encrypted cookie jars.
|
| | | | |
| | | | |
| | | | |
| | | | | |
The `EncryptedCookieJar` already calls it for us, so just delegate to its `parse` implementation.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
`SignedCookieJar`'s parse method already attempts to verify the message,
so we can just call super and try the old verifier if it fails.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Cuts down on the duplicated reading parts.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Gets rid of the option parsing and makes what the encryptor does stand out.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Lets us avoid worrying about parsing the options and doing just what we need.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Remove the clutter to make PermanentCookieJar's one change stand out.
|