Google frontend serves gzipped content even if the client doesn't ask for it

[Attila-Mihaly Balazs]

Hello,

This is something which I'm able to reproduce occasionally: for static content deployed on google app engine the frontend / edge cache sometimes serves the content gzipped even if the client doesn't ask for it (ie. it doesn't send an "Accept-Encoding" header). My application is deployed in the EU region. This isn't generally a problem since most (all?) browsers send Accept-Encoding: deflate, gzip, however cURL doesn't by default (only if you specify --compressed).

Perhaps the URL was first accessed by a browser supporting gzip, it was cached in the compressed format and is being (erroneously) served this way? Note: even when the response is unexpectedly compressed, it contains the correct "Content-Encoding: gzip" header, but cURL doesn't decompress it.

Cheers,
Attila

[Nick (Cloud Platform Support)]

Hey Attila,

An issue report like this should be posted to the Public Issue Tracker for App Engine, with some more details necessary to determine exactly what's happening:

1. The exact URL and resource type that this was observed for
2. Example request/response

This is necessary so we can attempt to determine what's happening and also so that we can attempt to reproduce the same behaviour from our own side.

When you make a report there, feel free to link it here and I'll be happy to take a look - we monitor the Issue Trackers daily, so it wouldn't take long to hear a response on your report anyways.

Cheers!

Nick
Cloud Platform Community Support

[Attila-Mihaly Balazs]

Hello,

Unfortunately I'm not able to reproduce this reliably (in fact I tried to repro yesterday before posting this message). If I manage a repro, I'll be sure to post a bug report (although, given how my last bug report about memory corruption on PHP instances fared I have no great hope) and also update this thread.

Regards,
Attila

[Nick (Cloud Platform Support)]

Hey Attila, 

Not to worry - if you can even manage to capture some of the details given, such as the request/response of a sample incident, the URL, etc., that could be enough. We have had issue reports of requesting gzip and not receiving it, but as far as I know, this has not been reported. It's worth mentioning that it technically follows the RFC doc:

If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.

So, setting "accept-encoding: identity" for curl should resolve this.

Cheers!

Nick

Cloud Platform Community Support

[Attila-Mihaly Balazs]

If I get a trace, I'll be sure to post it. There is also this short back-and-forth I had about the topic on the cURL mailing list: http://comments.gmane.org/gmane.comp.web.curl.general/15227

BTW, from the quote I understand that "the server SHOULD use the "identity" content-coding" - ie. sending with gzip encoding is incorrect if the client didn't request it :-)

Cheers,
Attila

[Alex Martelli]

On Tue, Jul 19, 2016 at 6:13 AM, Attila-Mihaly Balazs <dify...@gmail.com> wrote:

If I get a trace, I'll be sure to post it. There is also this short back-and-forth I had about the topic on the cURL mailing list: http://comments.gmane.org/gmane.comp.web.curl.general/15227

BTW, from the quote I understand that "the server SHOULD use the "identity" content-coding" - ie. sending with gzip encoding is incorrect if the client didn't request it :-)

No, the terms used in RFC standards are carefully defined (see https://www.ietf.org/rfc/rfc2119.txt) and acting against a `SHOULD` does not qualify as incorrect -- to quote RFC 2119, using `SHOULD` rather than `MUST` implies "there may exist valid reasons in particular circumstances when the

   particular behavior is acceptable or even useful". In this case, the "particular circumstances" might be that some legacy browsers don't properly send accept-encoding yet do correctly accept gzip encoded responses.

Alex

 

Cheers,
Attila

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-appengine.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/ba869ac8-28dd-488f-8623-9317f0289a2f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Attila-Mihaly Balazs]

Hello all,

This just happened again (and it seems to consistently reproduce), so I filed an issue on the issue tracker: https://issuetracker.google.com/issues/37938470

Additionally I also tried to specify "Accept-Encoding: identity" (ie. curl -v -H 'Accept-Encoding: identity' ...), but the Google Frotend server still returned "Content-Encoding: gzip", ignoring the client's specification about which encodings it can handle.

Attila