Echo compression and WOFF2 font causing ERR_CONTENT_LENGTH_MISMATCH

[JosefWN]

Description

Serving static content (Font Awesome 4.7.0), but having issues transferring the font file to the client browsers using Echo's Gzip compression.

Checklist

• [ x ] Dependencies installed
• [ x ] No typos
• [ x ] Searched existing issues and docs

Expected behaviour

File transfers successfully, just like it does when Gzip compression is disabled in Echo.

Actual behaviour

GET http://site.com/fonts/fontawesome-webfont.woff2?v=4.7.0 net::ERR_CONTENT_LENGTH_MISMATCH (at least in Google Chrome 55).

The transfer retries and succeeds the second attempt falling back to WOFF.

Steps to reproduce

Include font awesome CSS on a simple HTML page and make sure font files are available, enable Gzip compression and serve static.

Version/commit

Today's version from the trunk of Echo, but also older versions. Possibly since v3. This is a relatively new bug though, has worked in the past.

[vishr]

Sample code to debug?

[JosefWN]

All files necessary are included in the zip-file: test.zip

  ee := echo.New()
  ee.Use(mw.Gzip())
  ee.Static("/", "/test")

  if err := ee.Start(":80"); err != nil {
    ee.Logger.Fatal(err)
  }

[steveoc64]

Same issue, I have an app that uses gzip in echo, and it also happens to serve up fontawesome.css from local assets. Runs fine, no probs. Deployment is on FreeBSD 11, go 1.7.1, with nginx (minus gzip) sitting on top.

Just today, fired up a new FreeBSD server and installed + built the app on that. Went through "go get -u" on all tools, so that would have pulled in the latest echo as of today.

Getting the same error as @Puffton , on fontawesome.css, and a handful of large image assets. Other large image assets in the same app are fine though ??? odd.

Can work around it (for now) by turning off gzip in the echo portion of the app, and turning gzip on in the nginx layer that sits above it. That works at least.

Both of the code bases (working server vs today's installation) use the same go1.7.1 tarball for FreeBSDl, so Im guessing that they are using identical go compress/gzip libs.

In the meantime, will try and see whats causing the problem inside echo, o

[JosefWN]

WOFF2 is using a certain type of compression algorithm which I don't think for example WOFF is using (it's also compressed, but with another algo)... not sure it has anything to do with it though. It could explain why some large files work, while others don't, I meant.

[steveoc64]

My production server that is working fine, has this release of echo :

commit 0e7a9c1d497b84d79fca0d201638f393942e44a4
Author: Vishal Rana <vr@labstack.com>
Date:   Sat Dec 10 08:38:27 2016 -0800

    exposed default binder, tag for binding query params
    
    Signed-off-by: Vishal Rana <vr@labstack.com>

Looks like @vishr has been super busy since then.

[steveoc64]

All the images that are not working for me are .PNG of different sizes. Nothing always huge - 60k here, 3k there.

I have other larger jpegs in the same stream that work fine.

[vishr]

@Puffton please verify.

[JosefWN]

Looks like it worked, thanks!