Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New failures in Rack tests relating to deflater #7879

Open
headius opened this issue Aug 9, 2023 · 1 comment
Open

New failures in Rack tests relating to deflater #7879

headius opened this issue Aug 9, 2023 · 1 comment
Milestone

Comments

@headius
Copy link
Member

headius commented Aug 9, 2023

In 9.4.3.0 we fixed an issue in the jzlib-based deflater logic (#7814) but it seems there are still some issues causing failures in the Rack CI:

https://github.com/rack/rack/actions/runs/5747045920/job/15577430896

@bmckeough
Copy link

I noticed this recently when looking at the Rack project. All recent commits are failing the jruby test matrix and passing the other ruby versions in the test matrix.

It appears to me that the discrepancy between jruby and the other tested ruby runtimes is that jruby does not infer a GZIP mtime when no last-modified header is present. I'm basing this on the following:

  • The Rack::Deflater gzip test that specifies a last-modified header passes when run by jruby.
  • The other Rack::Deflater gzip tests which do not specify a last-modified header fail when run by jruby.
  • All of the Rack::Deflater gzip tests succeed when run by the other ruby runtimes in the Rack test matrix.
  • A review of Rack::Deflater and Rack::Deflater::GzipStream implementations, which populate ::Zlib::GzipWriter's mtime only if headers["last-modified"] is not nil.

Unfortunately it isn't immediately obvious to me where this defaulting logic for GZIP mtime should be added in jruby, if that is in fact the appropriate fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants