IssueTracker

I just got a mail that the following update was done to my request:

Updates:
    Labels: Language-Java


Why this change? I am running my appengine on python! Content-Encoding has nothing to
do with the appengine language.

Please explain.

Cheers,
Dieter

Request is to allow the Content-Encoding header to be set, specifically to pack200-gzip

We currently assume that Content-Encoding will only be used to request gzip compression.  It appears that we
should have consulted the IANA list of registered content codings (http://www.iana.org/assignments/http-
parameters) before making this assumption, as pack200-gzip is a valid coding and does imply different
semantics to the client.

I'll do some more investigation into the feasibility of this.

Thank you very much!

Yes - I believe it was a JSR long ago which introduced it into the IANA list. That's
why we never even thought that appengine would not support pack200-gzip until late
into the development process when we tried to use it.

Cheers,
Dieter

could someone explain why being able to set content-encoding is a security risk?

As far as I understand it there isn't. However this case is anyway special since
pack200-gzip is IANA standard.

From a user point of view all Google would have to do is allow specifying
pack200-gzip in app.yaml for a range of files or folders and then add the
Content-Encoding = pack200-gzip to the HTTP response header.

Unlike a few people I talked to believe, there is not more to do then changing the
HTTP response header. It doesn't mean that the server as to encode the served files
or something.

Still, there may be technical limitations on Google's end keeping them from doing it.
Perhaps somebody from Google could explain it in great detail. Maybe we find a
solution together.

Could we get some official commentary on implementing/fixing this? Either dynamic
Content-Encoding is not a security risk and someone could trivially enable it, or it
is and someone could post a short comment explaining why.

Hi Jeremy,

What do you need Content Encoding for? Are you also opting for pack200-gzip CE?

Dieter.Krachtus: yes, pack200 compresses my applet 6 fold. regardless, this platform
shouldn't have arbitrary limitations.

Also waiting for pack200-gzip encoding support by the Google appengine. I have even
tried bypassing this limitation by writing a simple servlet which will be responsible
for reading *.jar.pack.gz files back to the client, but even though it works on my
development environment, it does not when deployed on appengine.

Well a lot of stuff works on the dev server. Once deployed appengine will 'filter'
out all the 'wrong' headers.

The appengine team has acknowledged that they want to fix it. I guess we just have to
wait.

I've digged and tested many things before writing , Thinking a simple scenario,
client requests a url like xxtopic, we could get the releated topic ( after url
dispatching to a handler ) from datastrore, " gzip " the content, and also put
created content as gzipped to datastre ( may be memcache also ), and sent to client
wtih putting content-encoding : gzip, ( also we may need to check request headers
about accept content bu it's disabled ( even dev server ), what's the point, ok app
server could detect and gzip ( or deflate or wahtever ) if server script does not
interact the headers, but in my scenario, it's waste of cpu cycles, also unnecassary
.. Finally I would have both request and response headers about accept encoding, and
have permition  to unset request header to prevent app server to try gzip again ..
I've spent about 4-5 nights to find why I can not get the accept encoding headers,
finally found the code that unsets the accept headers in dev server and I assume same
thing applied on app server.. Please help , thanks

S.Firat SARLAR

Almost 2 years and no fix? Is this bug this on the radar? Estimates?

I, too, just ran into this. Still no fix?

I think the main problem is that this issue is flagged as missing feature and not as a bug which in my opinion it is. After such a long time this issue may well be forgotten. Perhaps somebody should resubmit a new issue report flagging this as a bug.

Submitted as a new bug: http://code.google.com/p/googleappengine/issues/detail?id=4292.

This problem also appears when attempting to serve .svgz files (gzip compressed SVG files). This images need to have the following headers to get browsers to display them:

Content-Type: image/svg+xml
Content-Encoding: gzip

https://jwatt.org/svg/authoring/#server-configuration

Is there any workaround to serve static svgz files ?

Also annoying for serving large javascript files. Apparently anything above 1 MB is not compressed automatically and there is no way to do it manually since the content-encoding header is stripped.

Disappointing that this is nearly four years old and still not fixed.

I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.

- Was this issue solved?
- It seems Content-Encoding header is still being stripped