https://code.jquery.com/jquery-2.2.4.min.js throwing GZip error on West US, Central US, South Central US locations

[vchandrasn]

We are seeing lot of GZip errors with https://code.jquery.com/jquery-2.2.4.min.js on West US, Central US, South Central US locations.

Below is the error message:

System.IO.InvalidDataException: The magic number in GZip header is not correct. Make sure you are passing in a GZip stream.
at System.IO.Compression.DeflateStream.EndRead(IAsyncResult asyncResult)
at Microsoft.VisualStudio.TestTools.WebStress.DataCaptureStream.EndRead(IAsyncResult asyncResult)
at Microsoft.VisualStudio.TestTools.WebStress.WebTestTransaction.ReadResponse(IAsyncResult result)

It looks like the CDN issue with above jQuery version on those locations.

EAST US, EAST US 2 locations don't throw this error message and serves the right content back.

Please fix/refresh the CDN issue for this jQuery library.

Thanks!

[dmethvin]

What are you using to decompress the file? Is it a browser? The error message you copy/pastaed does not seem like a browser error. Can you provide a link to a copy of the exact bits you get that cause the error?

[vchandrasn]

Hi Dave, The error is from Azure availability ping test and the web browser seems to be loading the jQuery without any issues (atleast from my computer in EAST US). It looks like the compressed version is expected to be returned back from the CDN whereas the uncompressed file is returned now. The issue seem to be started having from 8/23/2018 12 AM EST. I don't have the exact bits but here is what I got from Microsoft support: The CDN serving https://code.jquery.com/jquery-2.2.4.min.js is returning incorrect data. It is precisely what the error indicates: The magic number in GZip header is not correct. Make sure you are passing in a GZip stream This is not the first time we have seen odd errors from CDNs unfortunately The issue is that the request for a gzip file successfully returns and the response header states that the content is gzipped. If you actually look at the hex return however the file is not compressed. If the file IS compressed the first two bytes of the return value are supposed to contain the Magic Number for gzip which is: 0x1F, 0x8B . What is being returned instead by the CDN is uncompressed and instead 0x2F, 0x2A “/*”. We report this as an error because of the testing. We get the file back and the header says it is GZIP but we detect that it is not and report the error. Web Browsers are very forgiving in this regard and will often ignore the error if it occurs and retry to read this as a text field. Therefore this failed test will not affect web browser clients. Hope it helps!

…

On Fri, Aug 24, 2018 at 1:40 PM Dave Methvin ***@***.***> wrote: What are you using to decompress the file? Is it a browser? The error message you copy/pastaed does not seem like a browser error. Can you provide a link to a copy of the exact bits you get that cause the error? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4162 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVLPChAF_NzJNrzv3EydEpC0ldCKFo2iks5uUDqkgaJpZM4WLgfl> .

-- Chandra Venkataraman Lead .Net Developer

____ US 443-453-0131

____ jellyfish.net The Global Boutique Agency

[thomhubers]

Exactly the same issue here. Any chance of solving this issue?

[jsandersrocks]

Yes, you can solve this by having jquery update their server to return the correct data.

Re: GZIP Iisue with code.jquery.com CDN ?
4 minutes ago
Awaiting moderation!
The underlying issue is that that CDN is returning the incorrect Response header (or the source server that the CDN queries). This is quite easy to see with a tool like Fiddler.
If you query for the library and pass the GZIP header in upper case - which is perfectly legal per the RFC - you will see the response indicates that it is zipped, but the content is not compressed. That is the underlying problem.

For example:
GET https://code.jquery.com/jquery-migrate-1.2.1.min.js HTTP/1.1
Host: code.jquery.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Accept-Encoding: GZIP
Accept-Language: en-US,en;q=0.9

Returns:
HTTP/1.1 200 OK
Date: Tue, 28 Aug 2018 13:57:36 GMT
Connection: Keep-Alive
Accept-Ranges: bytes
Content-Encoding: gzip
Content-Length: 7199
Content-Type: application/javascript; charset=utf-8
Last-Modified: Fri, 24 Oct 2014 00:16:08 GMT
Server: nginx
ETag: W/"54499a48-1c1f"
Cache-Control: max-age=315360000
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
X-HW: 1535464655.dop009.at2.t,1535464655.cds012.at2.shn,1535464656.cds012.at2.c

But you will noticed that the content is returned in plain text and not compressed gzip as the Content-Encoding specifies. This is what causes the error mentioned in the original question. The return is not zipped as promised by the source server.

This is a fairly recent change/problem as in the past, the return data was compressed.

The fix is to ensure the source for the CDN (jquery's server) is returning compressed data when it says it is, or the CDN is adding this header when the content is not compressed with GZIP

https://forum.jquery.com/topic/gzip-iisue-with-code-jquery-com-cdn

[mgol]

If you query for the library and pass the GZIP header in upper case

@jsandersrocks Could you provide some source for the claim that Accept-Encoding header values are case insensitive? Once I have something I can work on forwarding the issue to our CDN provider.

[mgol]

@vchandrasn can you confirm if the test you described also sends the Accept-Encoding value as GZIP uppercase so that we know we're not talking about two different issues?

[vchandrasn]

Hi Michal, From what I could see the ping test does not send *Accept-Encoding* header at all. It only sends *Content-Encoding* header with value *gzip.* Thanks, Chandra

…

On Wed, Aug 29, 2018 at 8:51 AM Michał Gołębiowski-Owczarek < ***@***.***> wrote: @vchandrasn <https://github.com/vchandrasn> can you confirm if the test you described also sends the Accept-Encoding value as GZIP uppercase so that we know we're not talking about two different issues? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4162 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVLPCpjaoKiRzE2hex3ImmAN2vkDspfgks5uVo47gaJpZM4WLgfl> .

-- Chandra Venkataraman Lead .Net Developer

____ US 443-453-0131

____ jellyfish.net The Global Boutique Agency

[mgol]

@vchandrasn Content-Encoding is what the server should send together with the response. I'm asking what you're sending in the request to the server; there you should be specifying Accept-Encoding, not Content-Encoding.

[vchandrasn]

You are right. What I sent you is response header information. We are indeed sending Accept-Encoding header with *gzip, deflate, br* value.

…

On Wed, Aug 29, 2018 at 9:37 AM Michał Gołębiowski-Owczarek < ***@***.***> wrote: @vchandrasn <https://github.com/vchandrasn> Content-Encoding is what the server should send together with the response. I'm asking what you're sending in the request to the server; there you should be specifying Accept-Encoding, not Content-Encoding. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4162 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVLPCsEPshTnri_pIGvnxuKsvDulzvA7ks5uVpj-gaJpZM4WLgfl> .

-- Chandra Venkataraman Lead .Net Developer

____ US 443-453-0131

____ jellyfish.net The Global Boutique Agency

[jsandersrocks]

@mgol Absolutely!
Open Postman or Fiddler. In the composer of Fiddler for example send a request with the following headers:
GET https://code.jquery.com/jquery-migrate-1.2.1.min.js HTTP/1.1
Host: code.jquery.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Accept-Encoding: GZIP
Accept-Language: en-US,en;q=0.9

Then inspect the return. You will see that even though the Content-Encoding indicates that it is GZIP, in reality it is returned as Plain text and not compressed. It is OK not to compress the return value, however if the server does that, it must not set the Content-Encoding: gzip header. Feel free to email me at jsanders at Microsoft dot com if you need more!

PS this is a recent issue. Up until now, things worked fine. Also if you change the request to lower case gzip, you get the correct value.

[debugthings]

@mgol I am also working on this with @jsandersrocks. Looking at RFC7230 Section 4 the last paragraph states this explicitly.

EDIT: Also found in RFC7231 Section 3.1.2.1 which is referenced in the first paragraph of RFC7231 Section 5.3.4 on Accept-Encoding.

5.3.4. Accept-Encoding

The "Accept-Encoding" header field can be used by user agents to
indicate what response content-codings (Section 3.1.2.1) are
acceptable in the response. An "identity" token is used as a synonym
for "no encoding" in order to communicate when no encoding is
preferred.

3.1.2.1. Content Codings

All content-coding values are case-insensitive and ought to be
registered within the "HTTP Content Coding Registry", as defined in
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4)
and Content-Encoding (Section 3.1.2.2) header fields.

[mgol]

@debugthings Thank you! I'll follow up with the request to our CDN provider.

[gibson042]

Issue confirmed. Content coding values (which are the contents of Accept-Encoding) are case-insensitive per RFC 7231, but code.jquery.com sends a response with no encoding in response to Accept-Encoding: GZIP (or other variants that are not all lowercase), and—here's the issue—lies about that lack of encoding by also including Content-Encoding: gzip.

Transcripts, with ### comments added.

no Accept-Encoding

$ curl -sv http://code.jquery.com/jquery-2.2.4.min.js | head -c 10 | xxd
*   Trying 205.185.208.52...
* Connected to code.jquery.com (205.185.208.52) port 80 (#0)
> GET /jquery-2.2.4.min.js HTTP/1.1
> Host: code.jquery.com
> User-Agent: curl/7.47.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Aug 2018 14:04:40 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
< Content-Length: 85578 ### unencoded size: 85578
< Content-Type: application/javascript; charset=utf-8
< Last-Modified: Fri, 20 May 2016 17:24:41 GMT
< Server: nginx
< ETag: W/"573f4859-14e4a"
< Cache-Control: max-age=315360000
< Cache-Control: public
< Access-Control-Allow-Origin: *
< Vary: Accept-Encoding
< X-HW: 1535724280.dop013.ny3.t,1535724280.cds046.ny3.c
< 
{ [1460 bytes data]
00000000: 2f2a 2120 6a51 7565 7279                 /*! jQuery ### unencoded response
* Failed writing body (892 != 16384)
* Closing connection 0

no Accept-Encoding: gzip

$ curl -sv -H 'Accept-Encoding: gzip' http://code.jquery.com/jquery-2.2.4.min.js | head -c 10 | xxd
*   Trying 205.185.208.52...
* Connected to code.jquery.com (205.185.208.52) port 80 (#0)
> GET /jquery-2.2.4.min.js HTTP/1.1
> Host: code.jquery.com
> User-Agent: curl/7.47.0
> Accept: */*
> Accept-Encoding: gzip ### request for gzipped response
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Aug 2018 14:10:51 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
< Content-Encoding: gzip ### response is claimed to be gzipped
< Content-Length: 34834 ### compressed size: 34834
< Content-Type: application/javascript; charset=utf-8
< Last-Modified: Fri, 20 May 2016 17:24:41 GMT
< Server: nginx
< ETag: W/"573f4859-14e4a"
< Cache-Control: max-age=315360000
< Access-Control-Allow-Origin: *
< Vary: Accept-Encoding
< X-HW: 1535724651.dop012.ny3.t,1535724651.cds046.ny3.c
< 
{ [1460 bytes data]
00000000: 1f8b 0800 0000 0000 0003                 .......... ### response appears gzipped, cf. https://tools.ietf.org/html/rfc1952#page-6
* Failed writing body (1500 != 9899)
* Closing connection 0

no Accept-Encoding: GZIP

$ curl -sv -H 'Accept-Encoding: GZIP' http://code.jquery.com/jquery-2.2.4.min.js | head -c 10 | xxd
*   Trying 205.185.208.52...
* Connected to code.jquery.com (205.185.208.52) port 80 (#0)
> GET /jquery-2.2.4.min.js HTTP/1.1
> Host: code.jquery.com
> User-Agent: curl/7.47.0
> Accept: */*
> Accept-Encoding: GZIP ### unusual request for gzipped response
> 
< HTTP/1.1 200 OK
< Date: Fri, 31 Aug 2018 14:14:50 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
< Content-Encoding: gzip ### response is claimed to be gzipped
< Content-Length: 85578 ### …but the size is as big as an unencoded response :\
< Content-Type: application/javascript; charset=utf-8
< Last-Modified: Fri, 20 May 2016 17:24:41 GMT
< Server: nginx
< ETag: W/"573f4859-14e4a"
< Cache-Control: max-age=315360000
< Access-Control-Allow-Origin: *
< Vary: Accept-Encoding
< X-HW: 1535724890.dop004.ny3.t,1535724890.cds046.ny3.c
< 
{ [1460 bytes data]
00000000: 2f2a 2120 6a51 7565 7279                 /*! jQuery ### non-gzipped! >:(
* Failed writing body (2068 != 16384)
* Closing connection 0

[timmywil]

Moved issue to CDN repo. jquery/codeorigin.jquery.com#43 This is being addressed.