Greed: Error saving LevelSession

Bugs
1 
Error saving LevelSession: 0 error

I receive this error while modifying code in the editor for Greed. (I assume it’s the static debugger running.)

Error saving LevelSession: 400 Invalid header received from client

I receive this error while running the simulator. In Chrome’s inspection console, this error corresponds with

PATCH http://codecombat.com/db/level.session/537bc26e8fe668b406d4c019 400 (Invalid header received from client) vendor.js:460
Q.cors.t.crossDomain.send vendor.js:460
Z.extend.ajax vendor.js:438
t.ajax vendor.js:924
t.sync vendor.js:921
s.extend.sync vendor.js:835
s.extend.save vendor.js:856
a.save app.js:1365
a.exports.t.saveSession app.js:182
Hn.g vendor.js:709

I get these errors even with the default code loaded in the sim.

The debugger is also throwing “Unexpected end of input” for my code, though not the default code. I think that may be unrelated, but the above errors are the only things I can think of that might be triggering the error as I managed to get JSLint to stop complaining about my code, suggesting that it’s not an open-ended block…

Username is Sapid on the Ogres. I just threw my code up on the ladder so you can take a look at it. (Goodbye, ladder ranking…)

2

Hi @sapid, I’ll take a look at your ogre session.

I was unable to replicate the saving invalid headers problem on Chrome 35.0.1916.114 Mac OS X. Do you have any extensions installed?

3

about:chrome says I’m using Version 34.0.1847.137 m so I’ll see if updating helps.

The only extensions I have installed are Google Voice and Sidewise Treestyle Tabs. I’ll try disabling them and see if it helps.

After sleeping on it, I realized that it may be Privoxy. While not an extension, it IS a proxy, and I was discounting it because I set it to pass-through mode, but maybe it’s still munging something?

1 Like
4

Updating Chrome to Version 35.0.1916.114 m did not help. Disabling GVoice didn’t help.

Sending packets straight to the server rather than to the proxy fixed it, though. I started on Wednesday, though, and didn’t see the errors until Thursday. I doubt the proxy itself is munging the packets, as it didn’t throw the error in packet-editing mode on Wednesday (or in pass-through mode) and the errors persisted when I was using pass-through mode.

It might be something to do with the headers not being addressed to the server properly, perhaps?

5

We can take a look, sure. Can you give us the headers that your browser sends with Privoxy enabled on the request that breaks?