Project

General

Profile

Actions

Feature #13020

closed

Zlib.gzip and Zlib.gunzip

Feature #13020: Zlib.gzip and Zlib.gunzip

Added by naruse (Yui NARUSE) almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:78565]

Description

I added Zlib.deflate/inflate [Feature #4180] before, but writing/reading gzip is still too complex.
It should have shorthand method.


Related issues 1 (0 open1 closed)

Related to Ruby - Bug #13021: `Zlib.gunzip` modifies argument StringClosednaruse (Yui NARUSE)Actions

Updated by naruse (Yui NARUSE) almost 9 years ago Actions #1

  • Status changed from Open to Closed

Applied in changeset r57035.


Zlib.gzip and Zlib.gunzip [Feature #13020]

Encode and Decode gzip data without creating files.

Updated by normalperson (Eric Wong) almost 9 years ago Actions #2 [ruby-core:78566]

wrote:

I added Zlib.deflate/inflate [Feature #4180] before, but writing/reading gzip is still too complex.
It should have shorthand method.

I like the convenience, but I think encouraging use of
potentially large String buffers is dangerous.

It causes memory problems and even opens up DoS attacks.

So, I think it would be better if it used IO-like object
instead, to discourage slurping.

Maybe make it like IO.copy_stream:

Zlib.gzip(src_io, dst_io)
Zlib.gunzip(src_io, dst_io)

Slurpers can still use StringIO if they want to.

In general, I am against non-streaming APIs and want to
encourage processing data in predictable sizes to avoid
fragmentation and OOM.

Updated by znz (Kazuhiro NISHIYAMA) almost 9 years ago Actions #3

  • Related to Bug #13021: `Zlib.gunzip` modifies argument String added

Updated by naruse (Yui NARUSE) almost 9 years ago Actions #4 [ruby-core:78725]

Eric Wong wrote:

wrote:

I added Zlib.deflate/inflate [Feature #4180] before, but writing/reading gzip is still too complex.
It should have shorthand method.

I like the convenience, but I think encouraging use of
potentially large String buffers is dangerous.

It causes memory problems and even opens up DoS attacks.

So, I think it would be better if it used IO-like object
instead, to discourage slurping.

Maybe make it like IO.copy_stream:

Zlib.gzip(src_io, dst_io)
Zlib.gunzip(src_io, dst_io)

Slurpers can still use StringIO if they want to.

In general, I am against non-streaming APIs and want to
encourage processing data in predictable sizes to avoid
fragmentation and OOM.

There's already Zlib.deflate/inflate, which are memory based API.
And gzip also uses deflate/inflate.
Note that gzip has the length of original data at the end of data. (isize=origsize / (2^32))

Anyway IO.copy_stream like API sounds reasonable.
Current API needs to change interface to use keyword arguments to avoid using 2nd argument...

Actions

Also available in: PDF Atom