On Wed, Jun 11, 2008 at 8:30 AM, spicyj <spicyjalap...@gmail.com> wrote: > Anyone know how to write a Rack middleware to serve static files as > gzipped?
How about:
class GzipOutputFilter def initialize(app) @app = app end
def call(env) out = @app.call(env)
gzip = IO.popen('gzip', 'r+') gzip.write out[2] # handles String only, would be nice to check for IO object too gzip.close_write
out[1]['Content-encoding'] = 'gzip' out[2] = gzip
out end end
class HelloHandler def call(env) [ 200, { 'Content-type' => 'text/plain' }, 'hello, world' ] end end
use Rack::Lint use GzipOutputFilter run HelloHandler.new
> Anyone know how to write a Rack middleware to serve static files as > gzipped?
> I can see how to set the Content-Encoding header, but the file still > needs to be zipped up.
Here is a middleware adapted from Mongrel's Deflate Handler:
require 'zlib'
class Deflater include Zlib
def initialize(app) @app = app end
def call(env) accept = env['HTTP_ACCEPT_ENCODING'] status, headers, body = @app.call(env) if accept and accept.include? 'deflate' headers["Content-Encoding"] = "deflate" body = deflate(body) end [status, headers, body] end
def deflate(body) deflater = Deflate.new( DEFAULT_COMPRESSION, # drop the zlib header which causes both Safari and IE to choke -MAX_WBITS, DEF_MEM_LEVEL, DEFAULT_STRATEGY)
case body when IO body.rewind if body.respond_to? :rewind gzout = StringIO.new(deflater.deflate(body.read, FINISH)) body.close when String gzout = StringIO.new(deflater.deflate(body, FINISH)) end gzout.rewind gzout end
def call(env) accept = env['HTTP_ACCEPT_ENCODING'] status, headers, body = @app.call(env) if accept and [ 'deflate', 'gzip'].include? accept headers["Content-Encoding"] = "deflate" body = deflate(body) end [status, headers, body] end
Looks like the same functionality, and it should be -- the RFC2616
(HTTP/1.1) reads:
> The Accept-Encoding request-header field is similar to Accept, but restricts
> the content-codings (section 3.5) that are acceptable in the response.
Encoding names are not on the type/subtype form so we can't use MIMEParse as is for Accept-Encoding.
I don't think it's worth generalizing the current mimeparse.rb code to cover both Accept and Accept-Encoding; handling Accept-Encoding is much simpler than Accept (mostly because there's no need to deal with type specificity).
Once I extend my Accept-Encoding code to handle * and drop the complex regexp I'll ask the list for a review.
"Christoffer Sawicki" <christoffer.sawi...@gmail.com> writes: > I don't think it's worth generalizing the current mimeparse.rb code to > cover both Accept and Accept-Encoding; handling Accept-Encoding is > much simpler than Accept (mostly because there's no need to deal with > type specificity).
> Once I extend my Accept-Encoding code to handle * and drop the complex > regexp I'll ask the list for a review.
On Sat, Jun 28, 2008 at 6:07 PM, Christoffer Sawicki
<christoffer.sawi...@gmail.com> wrote: > Once I extend my Accept-Encoding code to handle * and drop the complex > regexp I'll ask the list for a review.
"Christoffer Sawicki" <christoffer.sawi...@gmail.com> writes: > On Sat, Jun 28, 2008 at 6:07 PM, Christoffer Sawicki > <christoffer.sawi...@gmail.com> wrote: >> Once I extend my Accept-Encoding code to handle * and drop the complex >> regexp I'll ask the list for a review.
>> On Tue, Jul 1, 2008 at 6:53 PM, Christian Neukirchen >> <chneukirc...@gmail.com> wrote: >>> "Christoffer Sawicki" <christoffer.sawi...@gmail.com> writes: >>>> I finished it yesterday: http://pastie.org/private/mfn66wqhxkjpky1rnvdha
>>>> Comments are very welcome - especially on the select_best_encoding tests.
On Tue, Jul 1, 2008 at 11:02 PM, Christoffer Sawicki
<christoffer.sawi...@gmail.com> wrote: > On Tue, Jul 1, 2008 at 11:01 PM, Christian Neukirchen <chneukirc...@gmail.com> wrote: >> Is the rest of the gzip stuff good enough for merging now? (And does >> it have tests?)
"Christoffer Sawicki" <christoffer.sawi...@gmail.com> writes: > On Tue, Jul 1, 2008 at 11:02 PM, Christoffer Sawicki > <christoffer.sawi...@gmail.com> wrote: >> On Tue, Jul 1, 2008 at 11:01 PM, Christian Neukirchen <chneukirc...@gmail.com> wrote: >>> Is the rest of the gzip stuff good enough for merging now? (And does >>> it have tests?)
I can't get a full test case, because gzip needs a header for the
mtime of the data, changing the output. Is there a good way to test
the output (maybe gunzipping the output and comparing it to the
original)? I should probably also change it to use the Last-Modified
header as the mtime.
Also, should this be in a separate file? Apache's mod_deflate handles
both deflate and gzip encodings.