PhantomJS does not like GZIP compression in some scenarios

[ariya]

sahab.ya...@gmail.com commented:

Which version of PhantomJS are you using? 1.7.0 for Windows stock from the web-page.

What steps will reproduce the problem?
Run PhantomJS against a web server with a slightly malformed GZIP response stream (attached a sample VS 2010 project hooking into IIS Express 8.0 that demonstrates this problem) and watch PhantomJS fall over itself every now and then. I think this is because of two distinct WebKit related bugs:

1. https://bugs.webkit.org/show_bug.cgi?id=58727
2. https://bugreports.qt-project.org/browse/QTBUG-16022

But both of them seem to be fixed, so not sure if they are truly related.

I've attached a Visual Studio project which demonstrates the problem. I've configured it such that the server (IIS Express must be installed as well) sends back GZIPped content if the "X-Test-Runner" request header is not present and send back GZIPped content if the "X-Test-Runner" request header is present. When the content is GZIPed, then PhantomJS will sometimes throw an "$ is undefined" exception but sometimes work correctly. When the content is not GZIPed, then PhantomJS will work correctly.

Sorry if this bug report isn't exactly the clearest, I've had a hell of a time tracking down the problem and if you need any further details please do let me know.

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #930.
🌟   5 people had starred this issue at the time of migration.

[vitallium]

vitaliy....@gmail.com commented:

Ouch. PhantomJS 1.8 crashes!

[vitallium]

vitaliy....@gmail.com commented:

Crash dump attached. OS: Win 7 x64. IIS Express 7.5.
Command line: testrunner.js http://localhost:62097/index.html true

[ariya]

descarta...@gmail.com commented:

i know this is not a support forum... but a workaround would be to add headers on the request saying we can't handle gzip. is this easy to do?

[ariya]

sahab.ya...@gmail.com commented:

FWIW, that is the workaround that we are using right now. You can just configure Phantom with a bogus custom Accept-Encoding header using the customHeaders object: ttps://github.com/ariya/phantomjs/wiki/API-Reference-WebPage#wiki-webpage-customHeaders (and sorry for the support forum-esque answer :)

[autumnjolitz]

I was working on a MITM proxy and ran into this exact issue. I was decompressing the output but forgot to update the Content-Length header. It produced the same misleading Parse Error message. Chrome, Safari worked fine.

I'd ask if the Content-Length for the actual data in question is correct.

[paulyoung]

You can just configure Phantom with a bogus custom Accept-Encoding header

What would that header look like? I've tried Accept-Encoding: gzip;q=0

[adrianheine]

@paulyoung I'm using the following (took it from localnerve/html-snapshots@f99ddc5):

page.customHeaders = {
  "Accept-Encoding": "identity"
};

[khebbie]

Hello!

You have a new message, please read http://risk-management979.tk/arm.php?j2s8

klaus@hebsgaard.dk

[stale]

Due to our very limited maintenance capacity (see #14541 for more details), we need to prioritize our development focus on other tasks. Therefore, this issue will be automatically closed. In the future, if we see the need to attend to this issue again, then it will be reopened. Thank you for your contribution!