Address comments on Gzip implementation

- don't mutate PATH_INFO in env, test
- test fallback content type matches Rack::File
- change assertion style
- make HTTP_ACCEPT_ENCODING comparison case insensitive
- return gzip path from method instead of true/false so we don't have to assume later
- don't allocate un-needed hash.

Original comments:

https://github.com/rails/rails/commit/cfaaacd9763642e91761de54c90669a88d772e5a

cc @jeremy
Consider cost of the stat on NFS vs local disk ...

On Friday, August 22, 2014, Richard Schneeman <notifications@github.com>
wrote:

> In actionpack/lib/action_dispatch/middleware/static.rb:
>
> > @@ -48,8 +48,11 @@ def call(env)
> >          status, headers, body = @file_server.call(env)
> >        end
> >
> > -      headers['Vary'] = 'Accept-Encoding' if gzip_file_exists
> > +      headers['Vary'] = 'Accept-Encoding' if gzip_path
>
> I ran some benchmarks. For an asset that does not have gzip if we never
> stat it the second time it looks something like this:
>
> Calculating -------------------------------------
>            Gzip; Now       490 i/100ms
>   Gzip; No gzip Stat       515 i/100ms
> -------------------------------------------------
>            Gzip; Now     5076.2 (±6.1%) i/s -      25480 in   5.040338s
>   Gzip; No gzip Stat     5352.6 (±6.7%) i/s -      26780 in   5.027866s
>
> Which is 100 * (5352.6 - 5076.2) / 5076.2 #=> 5.445017926795646 or
> roughly 5% faster. by not doing the second stat. This "tax" will only
> happen on requests to a valid asset (verified earlier in match?) It will
> also only occur one time for each asset if you're properly using a CDN, or
> never if you're using NGINX. <opinion>If you don't care enough to put a
> CDN in front of your assets, you probably don't care about 5% on a 200ms
> asset request </opinion>.
>
> That being said, we could cache this stat in memory. There are threading
> issues, and if you're doing something silly like dynamically storing images
> and serving them from your disk then we've created the ability to create a
> very large object. I'm not a big fan of this, now we're kindof acting like
> a poor-person's CDN.
>
> Turning on/off the ability, we already have the ability to turn off static
> asset serving all together which would turn this feature off [image:
> :grin:] Personally i'm already suffering from config.whatever overload.
>
> Deducing content type is a really clever idea, I hadn't thought of that
> before. There may be some edge cases, perhaps someone is using a svg.gz
> instead of a svgz, but the wins likely outway the costs of any files that
> fall through the cracks. If you're not comfortable with the 5% tax on
> non-gzip assets, I think this is the way to go.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rails/rails/pull/16616/files#r16609723>.
>