DWR

For more detail see mailing list thread: [dwr-user] Opera Mobile and Dwr 2

We're seeing this on a project running (an old...) Opera Mobile on set-top boxes. Calls to the server are being made OK, but responses are not being properly received by the client. Has there been any hidden progress on this issue?

I'm currently trying to confirm the claim by Danny Garcia Hernandez in http://markmail.org/message/pbu5azfvw6driivw that things work in 2.0-M2 and if so, I'll try to isolate in which version, and preferably changeset, this broke. Any other suggestions?

I've spent some time on this today and I did not get 2.0-M2 to run correctly on the box. 2.0-M1 was sufficiently different that our project wouldn't run, so I dropped that approach.

After hooking the dwr.engine._debug method into our logging system on the STB, registering default warning and error handlers, and adding a couple more debug lines to engine.js from the 2.0 branch, I get the following:

DEBUG | DWR | Sending batch'
DEBUG | DWR | _stateChange: readyState=3, responseLength=61, status=200'
DEBUG | DWR | 瑨牯眠❡汬潷卣物灴呡杒敭潴楮朠楳⁦慬獥⸧㬍ਯ⼣䑗刭䥎卅剔ഊ⼯⍄坒ⵒ䕐䱙ഊ摷爮敮杩湥⹟牥浯瑥䡡湤汥䍡汬扡捫⠧ㄳ✬✰✬湵汬⤻ഊ'
DEBUG | DWR | _stateChange: readyState=4, responseLength=61, status=200'
DEBUG | DWR | 瑨牯眠❡汬潷卣物灴呡杒敭潴楮朠楳⁦慬獥⸧㬍ਯ⼣䑗刭䥎卅剔ഊ⼯⍄坒ⵒ䕐䱙ഊ摷爮敮杩湥⹟牥浯瑥䡡湤汥䍡汬扡捫⠧ㄳ✬✰✬湵汬⤻ഊ'
WARN | DWR | Invalid reply from server'
DEBUG | DWR | _stateChange: readyState=1, responseLength=none, status=0'
DEBUG | DWR | '
DEBUG | DWR | Sending batch'
DEBUG | DWR | _stateChange: readyState=3, responseLength=61, status=200'
DEBUG | DWR | 瑨牯眠❡汬潷卣物灴呡杒敭潴楮朠楳⁦慬獥⸧㬍ਯ⼣䑗刭䥎卅剔ഊ⼯⍄坒ⵒ䕐䱙ഊ摷爮敮杩湥⹟牥浯瑥䡡湤汥䍡汬扡捫⠧ㄴ✬✰✬湵汬⤻ഊ'
DEBUG | DWR | _stateChange: readyState=4, responseLength=61, status=200'
DEBUG | DWR | 瑨牯眠❡汬潷卣物灴呡杒敭潴楮朠楳⁦慬獥⸧㬍ਯ⼣䑗刭䥎卅剔ഊ⼯⍄坒ⵒ䕐䱙ഊ摷爮敮杩湥⹟牥浯瑥䡡湤汥䍡汬扡捫⠧ㄴ✬✰✬湵汬⤻ഊ'
WARN | DWR | Invalid reply from server'

The lines of various odd symbols are the xhr.responseText and seems to be binary data where text data is expected. I'm not as expert in HTTP as I'd like to be, and perhaps, more expert in javacript than I'd like to be, but is this disagreement between the client and the server about whether the content should be compressed?

This is a character encoding issue. The server sends back byte-per-character text, which the browser interprets as 16-bit unicode and that's the string that you see above. I'll attach a patch in a moment which detects this state of affairs and re-interprets the .resultText. With this change I've gotten our rather large system to run correctly.

Perhaps it would be possible to get agreement about the character encoding so that this hack isn't needed?

Patch against the 2.0 branch which fixes xhr responses on opera mobile.

Unfortunately my patch above is... not fast. After adding a couple of debug lines, I see:
DEBUG | DWR | About to reinterpret 12409 16-bit characters
DEBUG | DWR | Time: 29598ms

I can't see a good way to reduce this time. Any ideas about how to avoid this problem completely?

Was any progress ever made here?