Jetty defaults to non-UTF8 on Windows

[tresf]

Some interesting behavior...

1. Start QZ Tray from IntelliJ, signing works.
2. Start QZ Tray from installer, signing does not work.

Steps to reproduce

1. Create a raw message using the 2.0 branch where the data contents contain unicode. e.g.

   var data = [ "€" ];
   qz.print(config, data);

2. Configure signing (in my case, I configured for POST).
3. Start QZ Tray from the desktop installer (NOT IntelliJ)
4. Using a Windows machine load the sample page and try to print the raw UTF8 commands silently.
5. Observe the warning is displayed.

Background

After several hours of trial and error, a client sent this PHP work-around for instances running from the installer: $req = iconv("UTF-8", "CP1252",$_POST['request']);

This is obviously a terrible solution as it assumes Jetty is interpreting the message as CP1252 as well.

At first I thought we we're missing a Jetty preference... Here's are two related articles: http://stackoverflow.com/a/31854430/3196753 http://stackoverflow.com/questions/4214111/jetty-character-encoding-issue

Workaround

A possible workaround on Windows:

java -jar -Dfile.encoding=UTF8 "%PROGRAMFILES%\QZ Tray\qz-tray.jar"
----------^

[akberenz]

On working with a similar issue caused by plus signs, I came upon a lot of references stating it was common to hash a message before signing it. This will give us a fixed length and prevent issues with special characters. Implemented in aa71578b6de26952145405ba44d0734903d817e7, we hash it with sha-256 browser side before sending to the signing server, and then again on the QZ software for verifying. This means users won't have to hash on their server (unless self-signing), but we do gain another soft requirement (overridable via qz.api.setSha256Type)

[akberenz]

If you can verify that this encoding problem doesn't affect anything else, we can close this issue.

[tresf]

Are we sure this is the correct approach?

If data is making it incorrectly into the WebSocket, that is a problem. Fixing the signature is a bandaid to the underlying problem, no?

@robertcasto opinions welcome here.

[tresf]

P.S. I do like the idea of sending less data to the server.

[akberenz]

I agree, I've added (not yet pushed) an explicit call to UTF-8 on string<->byte conversions, which was likely the issue with signing. But I haven't seen this as an issue elsewhere, ie printing an image called image_€.png works just fine. Without knowing what else is affected (if anything), I cannot fix it properly.

[tresf]

printing an image called image_€.png works just fine

That sounds fishy. This all was through the desktop, not the IDE?

[tresf]

Also, another concern of mine is the byte length for each character. Can we definitively say that CP1252, ISO-8859-1, or whatever's being defaulted here can hold every UTF8 character we can throw at it?

[tresf]

We're already rolling our own stringify (albeit for Prototype compat) Perhaps this... http://stackoverflow.com/a/4901205/3196753

[tresf]

Related #150.

Closing per user feedback, testing and via aa71578, 200eac7.