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

Problem serving precompressed files with directory handler #1676

Closed
avitale opened this issue Jun 1, 2014 · 3 comments
Closed

Problem serving precompressed files with directory handler #1676

avitale opened this issue Jun 1, 2014 · 3 comments
Assignees
Labels
bug Bug or defect
Milestone

Comments

@avitale
Copy link

avitale commented Jun 1, 2014

Hi, I am having problems serving precompressed files with the directory handler.
While the file handler serves the precompressed files, the directory handler seems to skip them and compress the original ones.
You can find a failing test below.
For test purposes, the precompressed file is set larger than the original file, so it is easier to distinguish it in case the server is compressing the orginal file.

// Load modules
var Fs = require('fs');
var Lab = require('lab');
var Hapi = require('hapi');
var Zlib = require('zlib');

// Test shortcuts
var expect = Lab.expect;
var before = Lab.before;
var describe = Lab.experiment;
var it = Lab.test;

describe('Response', function () {

    describe('Gzip', function () {

        before(function (done) {
          var uncompressedContent = '//This is the uncompressed test file';
          var precompressedContent = '//This is the pre-compressed test file. It should be longer than the uncompressed one';
          Fs.writeFileSync('./testFile.js', uncompressedContent);
          Zlib.gzip(precompressedContent, function(err, result){
            Fs.writeFileSync('./testFile.js.gz', result);
            done();
          })
        });

        it('File handler: returns a gzipped file using precompressed file', function (done) {

            var content = Fs.readFileSync('./testFile.js.gz');

            var server = new Hapi.Server();
            server.route({ method: 'GET', path: '/file', handler: { file: { path: './testFile.js', lookupCompressed: true } } });

            server.inject({ url: '/file', headers: { 'accept-encoding': 'gzip' } }, function (res) {

                expect(res.headers['content-encoding']).to.equal('gzip');
                expect(res.headers['content-length']).to.not.exist;
                expect(res.payload.length).to.equal(content.length);
                done();
            });
        });        

        it('Directory handler: returns a gzipped file using precompressed file', function (done) {

            var content = Fs.readFileSync('./testFile.js.gz');

            var server = new Hapi.Server();
            server.route({ method: 'GET', path: '/{p*}', handler: { directory: { path: './', lookupCompressed: true } } });

            server.inject({ url: '/testFile.js', headers: { 'accept-encoding': 'gzip' } }, function (res) {

                expect(res.headers['content-encoding']).to.equal('gzip');
                expect(res.headers['content-length']).to.not.exist;
                // The following fails
                expect(res.payload.length).to.equal(content.length);
                done();
            });
        });
    });
});
@hueniverse hueniverse added the bug label Jun 1, 2014
@steverandy
Copy link

Having the same issue. It seems internally hapi checks for accept-encoding header and always gzip response if accept-encoding gzip is present.

@hueniverse hueniverse added this to the 6.0.3 milestone Jul 10, 2014
@hueniverse hueniverse self-assigned this Jul 10, 2014
@mindbits
Copy link

Is there a way to disable gzip for certain file types like png, jpg etc.?

this happens with a reply.file(image) :

content-encoding:gzip content-type:image/jpeg

@hueniverse
Copy link
Contributor

@mindbits That's a good idea. I would even turn it on by default on file types known to not benefit from compression.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Bug or defect
Projects
None yet
Development

No branches or pull requests

4 participants