Is zlib compatible with HTTP-gzip-output-compression?
I tried the following short code and I get a really good looking response,
but all browsers display only the compressed data. It seems, that they
don’t unzip ?
How are you running this? As a CGI under a webserver, or is there a Ruby TCP
server which is not shown?
As a CGI, the webserver would override your choices of transfer-coding and
so on. In that case, I think you should leave off the ‘chunking’ and size
fields, and just send the compressed file directly after the headers. For
example, when sqwebmail uses gzip compression, it works in the normal way
but just adds a “Content-Encoding: gzip” header.
If it’s a standalone-server, have you got the rest of the code you’re
running this with?
Regards,
Brian.
···
On Fri, May 16, 2003 at 10:10:02PM +0900, Dominik Werder wrote:
Is zlib compatible with HTTP-gzip-output-compression?
I tried the following short code and I get a really good looking response,
but all browsers display only the compressed data. It seems, that they
don’t unzip ?
Is zlib compatible with HTTP-gzip-output-compression?
Indeed, it should be, zlib is the same library used by most free http
clients to decompress.
require ‘zlib’
zipped = Zlib::Deflate.deflate data, 9
How are you running this? As a CGI under a webserver, or is there a Ruby
TCP
server which is not shown?
I’m running it with mod_ruby
I checked the response with this little 2 liner we’re discussing in the IO
blocking thread, and the ouput is principially the same as a PHP-gzip-
output-buffering response. I can’t tell any difference, only the compressed
data itself changes of course, and the chunk-byte-size of course…
As a CGI, the webserver would override your choices of transfer-coding
and
No, it doesn’t. Seems working to me. See above.
so on. In that case, I think you should leave off the ‘chunking’ and size
fields, and just send the compressed file directly after the headers. For
example, when sqwebmail uses gzip compression, it works in the normal way
but just adds a “Content-Encoding: gzip” header.
Tried too.
Here is the solution that works best for me.
Unfortunately I had to introduce the class IOBuffer because the
Zlib::GzipWriter can only write to IO objects. So I faked one by providing
just the write method. Any other solution? Is there an IO compatible
buffering class already?
OK, heres the working code (GPL
— SNIP —
data = ‘Thats a Good Thing ™ @ ’ << Time.new.to_s <<
’!’
class IOBuffer
def initialize
@buf=’‘
end
def write s=’'
if s!=nil @buf << s
s.length
end
end
def buf @buf
end
end
require ‘zlib’
buffer=IOBuffer.new
z=Zlib::GzipWriter.new(buffer, 9)
z.write data
z.close
Ah, that’s not something I use. But I can trade you a working CGI:
#!/usr/local/bin/ruby -w
data = IO.popen(“cat /etc/motd | gzip -c”,“r”).read
puts “Content-Type: text/plain”
puts “Content-Encoding: gzip”
puts
print data
This works fine for me; at least Mozilla and Lynx both display the
uncompressed data. Maybe you can use this as a starting point to work out
how to do the same thing under mod_ruby.
Cheers,
Brian.
···
On Fri, May 16, 2003 at 10:40:00PM +0900, Dominik Werder wrote:
How are you running this? As a CGI under a webserver, or is there a Ruby
TCP
server which is not shown?
I’m running it with mod_ruby
Content-Encoding: deflate
Good hint, Opera 7.10 does it, but not mozilla and IE
Perhaps ethereal will be helpful here, you could use it to capture the
http session and see it’s content(See “Tools->Follow TCP Stream”)
StringIO (it’s a new feature in 1.8, but for 1.6.8 you can install the ‘1.6
to 1.8 shim’ which is available from RAA)
Regards,
Brian.
···
On Sat, May 17, 2003 at 11:06:34PM +0900, Dominik Werder wrote:
Here is the solution that works best for me.
Unfortunately I had to introduce the class IOBuffer because the
Zlib::GzipWriter can only write to IO objects. So I faked one by providing
just the write method. Any other solution? Is there an IO compatible
buffering class already?
Good hint, Opera 7.10 does it, but not mozilla and IE
Perhaps ethereal will be helpful here, you could use it to capture the
http session and see it’s content(See “Tools->Follow TCP Stream”)
I captured the output already (thanks for hint) but I don’t know how to
verify the compressed data block. All other seems to be OK, a PHP setup
delivered the same headers, only the compressed data differed…
No, I think you’re right. I wrote it that way because I started using a
bidirectional pipe, then changed my mind when I realised I could pipe the
uncompressed data directly into gzip within IO.popen - but didn’t optimise
it as far as yours
Brian.
···
On Fri, May 16, 2003 at 11:17:57PM +0900, Michael Campbell wrote:
Ah, that’s not something I use. But I can trade you a working CGI:
#!/usr/local/bin/ruby -w
data = IO.popen(“cat /etc/motd | gzip -c”,“r”).read
puts “Content-Type: text/plain”
puts “Content-Encoding: gzip”
puts
print data
Is “cat” necessary there, or am I missing something? Would:
