Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Gzip Compression for VideoPress JS served via SSL not working in Firefox #864

Closed
EnigmaSolved opened this Issue · 6 comments

4 participants

@EnigmaSolved

Currently when the VideoPress Javascript (https://v0.wordpress.com/js/videopress.js?ver=1.09) is served via SSL in Firefox (30.0, on Windows 7 Pro x64) it is not being compressed with gzip.

Response Header from Firefox:

Cache-Control   max-age=31536000
Content-Type    application/x-javascript
Date    Wed, 16 Jul 2014 15:25:52 GMT
Expires Thu, 16 Jul 2015 15:25:52 GMT
Server  nginx
Vary    Accept-Encoding
X-Firefox-Spdy  3.1

And Firefox reports a size of 12.4 KB, when it should be ~3.8 KB compressed.

Response Header from Chrome:

cache-control:max-age=31536000
content-encoding:gzip
content-type:application/x-javascript
date:Wed, 16 Jul 2014 15:29:09 GMT
expires:Thu, 16 Jul 2015 15:29:09 GMT
server:nginx
status:200 OK
vary:Accept-Encoding
version:HTTP/1.1

And Chrome shows the correct ~3.8 KB compressed size.

I recently encountered the same issue with jsDelivr and CloudFlare:
jsdelivr/jsdelivr#993. I strongly encourage reviewing that thread and in particular the comments by @terinjokes (eg, jsdelivr/jsdelivr#993 (comment)) as he was involved in the technical work of addressing things on the server end.

Thanks! :)
Sean

@blobaugh

The comments in the other thread indicate that when using spdy Firefox does not send the accept encoding header that includes gzip.

The server component is probably looking for that header to ensure it sends back a compatible stream.

@EnigmaSolved is Chrome asking for gzip?

@EnigmaSolved

Here's the Chrome Request Header:

:host:v0.wordpress.com
:method:GET
:path:/js/videopress.js?ver=1.09
:scheme:https
:version:HTTP/1.1
accept:*/*
accept-encoding:gzip,deflate,sdch
accept-language:en-US,en;q=0.8
cache-control:max-age=0
referer:https://enigmasolved.com/cms-dev/
user-agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

So yes, as far as what I can tell via Chrome Dev Tools, Chrome is asking for gzip (assuming that is accurate, unlike with Firefox currently).

I agree with your thinking (that the server is likely looking for that header).

@terinjokes

With my custom version of spdycat that doesn't send the Accept-Encoding header.

$ spdycat -nv 'https://v0.wordpress.com/js/videopress.js?ver=1.09'
[  0.170] NPN select next protocol: the remote server offers:
          * spdy/3.1
          * http/1.1
          NPN selected the protocol: spdy/3.1
[  0.232] Handshake complete
[  0.233] send SYN_STREAM frame <version=3, flags=1, length=212>
          (stream_id=1, assoc_stream_id=0, pri=3)
          :host: v0.wordpress.com
          :method: GET
          :path: /js/videopress.js?ver=1.09
          :scheme: https
          :version: HTTP/1.1
          accept: */*
          user-agent: spdylay/1.2.6-DEV
[  0.283] recv SETTINGS frame <version=3, flags=1, length=20>
          (niv=2)
          [4(0):100]
          [7(0):2147483647]
[  0.283] recv WINDOW_UPDATE frame <version=3, flags=0, length=8>
          (stream_id=0, delta_window_size=2147418111)
[  0.287] recv SYN_REPLY frame <version=3, flags=0, length=281>
          (stream_id=1)
          :status: 200 OK
          :version: HTTP/1.1
          cache-control: max-age=31536000
          content-type: application/x-javascript
          date: Wed, 16 Jul 2014 18:47:35 GMT
          expires: Thu, 16 Jul 2015 18:47:35 GMT
          server: nginx
          vary: Accept-Encoding
[  0.290] recv DATA frame (stream_id=1, flags=0, length=7300)
[  0.336] recv DATA frame (stream_id=1, flags=0, length=5392)
[  0.336] recv DATA frame (stream_id=1, flags=1, length=0)
[  0.336] send GOAWAY frame <version=3, flags=0, length=8>
          (last_good_stream_id=0)

And when sending the header

$ spdycat -nv -H'Accept-Encoding: gzip, deflate' 'https://v0.wordpress.com/js/videopress.js?ver=1.09'
[  0.582] NPN select next protocol: the remote server offers:
          * spdy/3.1
          * http/1.1
          NPN selected the protocol: spdy/3.1
[  0.633] Handshake complete
[  0.634] send SYN_STREAM frame <version=3, flags=1, length=248>
          (stream_id=1, assoc_stream_id=0, pri=3)
          :host: v0.wordpress.com
          :method: GET
          :path: /js/videopress.js?ver=1.09
          :scheme: https
          :version: HTTP/1.1
          accept: */*
          accept-encoding: gzip, deflate
          user-agent: spdylay/1.2.6-DEV
[  0.681] recv SETTINGS frame <version=3, flags=1, length=20>
          (niv=2)
          [4(0):100]
          [7(0):2147483647]
[  0.682] recv WINDOW_UPDATE frame <version=3, flags=0, length=8>
          (stream_id=0, delta_window_size=2147418111)
[  0.686] recv SYN_REPLY frame <version=3, flags=0, length=309>
          (stream_id=1)
          :status: 200 OK
          :version: HTTP/1.1
          cache-control: max-age=31536000
          content-encoding: gzip
          content-type: application/x-javascript
          date: Wed, 16 Jul 2014 18:48:55 GMT
          expires: Thu, 16 Jul 2015 18:48:55 GMT
          server: nginx
          vary: Accept-Encoding
[  0.731] recv DATA frame (stream_id=1, flags=0, length=3548)
[  0.731] recv DATA frame (stream_id=1, flags=1, length=0)
[  0.731] send GOAWAY frame <version=3, flags=0, length=8>
          (last_good_stream_id=0)
@blobaugh

Thanks @terinjokes. Def looks like it is a server side issue. Because the client is not requesting gzip it makes to not send out the gzip version just in case the client cannot handle it. Does that sound right?

@terinjokes

@blobaugh Not really. Clients connecting over SPDY are required to support gzip responses. From Firefox's point of view, it's pointless to send it.

@EnigmaSolved

Just wanted to report that this appears to be fixed now:

Firefox Response Header (for https://v0.wordpress.com/js/videopress.js?ver=1.09):

Cache-Control   max-age=31536000
Content-Encoding    gzip
Content-Type    application/x-javascript
Date    Sat, 30 Aug 2014 12:22:43 GMT
Expires Sun, 30 Aug 2015 12:22:43 GMT
Server  nginx
Vary    Accept-Encoding
X-Firefox-Spdy  3.1
x-ac    2.iad _iad

And Firefox is reporting the correct compressed file size of ~3.5 KB.

So I'm closing this. Thanks to all who worked on the behind-the-scenes pieces to get this fixed!! :)
Sean

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.