Downloading a video fails with chrome ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION

xBot150

Server: 0.80.2 on rasPi3 (SD-Image + updated to 0.80.2 just now)
Chrome: 54.0.2840.99 m

... bails out with ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION

Repro: try to download a video from Printer -> Webcam -> Records -> ... Button in the action-column

Works fine with Firefox 50.0.0 (updating right now..) but here I get the slightly scary "oops, lost connection"-message

Repetier

In

http://stackoverflow.com/questions/13578428/duplicate-headers-received-from-server </div><div>

I found that the filename could be bad causing this. Are there any commas or semicolon in your filename? What is the filename where this happens. Just tried with my files and it worked so that would be a reasonI could think of.

Firefox works stable without connection lost so far for me. Is the pi connected with cable or wifi? With wifi I get this sometimes regardless of browser type as it is not so stable as I'd like it to be. That is not the biggest issue as it reconnects automatically and does not affect the print, but not nice to have.

xBot150

finally got to it:
you are right, it the filename seems to be the cause.

lifted via "copy link location":
http://repetierserver/timelapse/download/xBot_150?entry=20161128T191025_iPad3%2C_iPhone5_iPhone5s_Stand_80deg-iphone_5 -> chrome complains bitterly, FF downloads it but "Connection lost" pops up

http://repetierserver/timelapse/download/xBot_150?entry=20161201T185543_PTW-36-1-PT-0336_Side_Plate -> works with chrome (no complaints re connection loss), FF: same as above (1)

I usually give the filename suggested by repetier-host a nod and upload the g-code as it is; if this causes problems with chrome I'm happy to clean up the filename ;-)

(1) FF seems to lose connection sometimes anyways and eats memory like crazy on my machine; if I leave FF open on the control-tab while a print is running it usually becomes unresponsible after _30min, 1GB memory + ₈₀% CPU for FF alone and that gets old fast with my dainty box here)
Chrome happily chugs on with _80MB and no next to no CPU-load...

btw: no wlan, rasPi and PC are on switched CAT5 (the connection to the router upstairs is a pair of netgear-powerline-thingies but this shouldn't matter here).

Repetier

Thanks for clarification. Will add a filaname fix in server so that problem should then not exist any more.

Regarding firfox it sounds like a memory leak. Will check if I can see where it leaks. Timeouts may be related to that.

Repetier

One more question, which page are you viewing in firefox that you run out of memory? SInce the page has influence on the code used this might be important.

xBot150

... of course it doesn't occur if one watches FF like a hawk ...

Somehow I feel this is not connected to <page> per se but instead it gets triggered by <sequence>, e.g. connect -> download Video -> move a axis or two -> preheat -> start a print -> (E)STOP it cos' some tool forgot to wipe the nozzle -> watch the temp-curves -> (...and somewhere Firefox throws its hands up ...)

If it helps:
no addons except Ghostery and uBlock Origin (disabled for httq://repetierserver) and the unavoidable extensions installed my mozilla itself.

/if chrome does what I want I'm a happy camper.

Repetier

At least I found the timeout when downloading bug. If you try this firefox disconnects websockets before detecting that it does not need to open a new page, but then it is too late. Chrome is more clever here. Now I download into a invisible iframe and both are happy:-)

Leave the memory thing open until someone or myself finds the magical sequence or condition needed to get a memory leak.

xBot150

Followup: I could not repro this (really obscure) "I wanna be a memory-hog now"-behavior of Firefox again..
/didn't change anything here except FF wanted an update or two since then.

Feel free to close & thanks for your really really good support!