Jeremy Evans

> And your words that it was nothing more than an accident made me very sad. I'm sorry to hear that. I realize this is disappointing to you, and could...

Rack's parameter parsing has always had the idea of never raising an error based on the format of the parameter name. I'm on the fence regarding changing the parsing to...

> In other words, you are asserting that: > > ``` > Rack::Utils.parse_nested_query("a[b[c]]=x") > # => {"a"=>{"b[c"=>{"]"=>"x"}}} > ``` > > is the best we can do? I think it's...

The expected use case is if you modify `env['QUERY_STRING']` or `env['rack.input']`, you can call the method to remove any cached values, so that Request#{GET,POST} use the new query string and...

> Right but we can remove the automatic cache invalidation without introducing manual cache invalidation? Certainly it is possible. Introducing manual cache invalidation allows the user currently relying on automatic...

My understanding is @tenderlove, @ioquatix, and I all want to remove the automatic cache invalidation. If a user modifies `rack.input` or `QUERY_STRING`, `Rack::Request` should not attempt to detect that and...

To me, whether the modification is done directly by the user's code or indirectly by some other code the user is choosing to run does not matter. Maybe @tenderlove or...

Do we want to support manual cache invalidation when deprecating automatic cache invalidation? I'm fine either way, as long as automatic cache invalidation is deprecated.

I removed the explicit methods for manual cache invalidation. So now the warning just warns about the change of behavior, but does not provide any instructions for fixing the situation....

To support this and potentially other compression algorithms, I think we should provide a Deflater option for custom deflaters: ``` use Rack::Deflater, deflaters: {"zstd"=>lambda{|headers, body| ...}} ``` The callable would...