In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in.

When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers:
1. Chrome fails with 401 error code and the log-in screen is not displayed at all.
2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds.

But in a different application, using Atmosphere - both connections fails:
1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling
2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info)
Here is the related discussion on the Atmosphere users group:
https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc

There is test WAR and source in the Atmosphere forum to reproduce the problem.