User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160811031722 Steps to reproduce: When I used Firefox 45 the request of websocket connection had no problem. Recently, I upgraded the Firefox, its version is 48. and then I request the connection with the following HTTP header GET /StreamingServer/ HTTP/1.1 Host: 192.168.123.54 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Sec-WebSocket-Version: 13 origin: http://192.168.123.54 Sec-WebSocket-Extensions: permessage-deflate Sec-WebSocket-Key: ng+5fTZv46kgx2hj/LFBPQ== Cookie: PHPSESSID=e9v9ceu9t1at0q1c7ppmi54p95 Connection: keep-alive, Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Actual results: After then the websocket request did not work. Always a bad request had been returned as the following. HTTP/1.1 400 Bad Request Access-Control-Allow-Origin: http://192.168.123.54 Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: Authorization, Content-Type, If-None-Match Access-Control-Expose-Headers: WWW-Authenticate, Server-Authorization Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, OPTIONS Access-Control-Max-Age: 60 Cache-Control: public, max-age=2 Content-Type: text/html Content-Length: 349 Date: Wed, 17 Aug 2016 10:22:46 GMT Server: lighttpd/1.4.35 Expected results: I wonder why the request got the bad request error. The wierd thing is the issue has been resolved when I set "Option > Privary > History : FireFox will : Never remember history" .
Firefox: 48.0.1, Build ID: 20160817112116 User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0 Hi Cheung, Can you please provide a minimal test case in order to test this issue? I have tested this using a created local page, but I could not reproduce this issue. Also, can you please retest this using latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/PNe90E).
Sweungwon, thanks for the test case, but it's not enough to reproduce the problem for us. What we also need is the server. The address 192.168.138.231 suggests that it is a server running only in your local network, inaccessible from outside. Hence, I'd like to ask you to produce a log file, please see  on how to do it. Please add nsWebSocket:5 module to the NSPR_LOG_MODULES environment variable as well, so it should look like: NSPR_LOG_MODULES=timestamp,rotate:200,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,nsWebSocket:5 Then run Firefox and reproduce the problem (just the problem, best in a clean profile). Thanks.  https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Sweungwon, please set: NSPR_LOG_MODULES=timestamp,rotate:200,nsHttp:5,nsSocketTransport:5,nsStreamPump:5,nsHostResolver:5,nsWebSocket:5 and run again. the log you've sent is not sufficient.
Dear Bambas. I sent the log again after resetting the configuration. Plase check your email. Regards.
The reporter sent me two logs, both from Fx48. One with Never remember history 'OFF' (default), which gets a 400 response to web socket request. Other one with Never remember history 'ON' which receives expected 101 Protocol Switch response. I can see that in the 400 case we send the "origin" header name all lower case. In the 101 case we send it 'correctly' as "Origin". I can't see in the log where this is set wrong, but something tells me that some code related PB mode might be involved. Jason, are you aware of any recent changes in WebSocket code regarding origin request header and PB mode?
Thanks Sweungwon for all the logs and info you provided in private mails! This is not a Firefox/Gecko bug. The lighttpd server is not willing to accept "origin" header in the lower case form. And, apparently, some add-on is messing with the header name (not us). Closing as INVALID.