Thanks for the test case. I will be making a couple changes in jetty, however they won't really help you with this type of webapp setup (ie basic auth coupled with all resources behind protected urls). In your case, the 1st request for the hello.jsp will trigger the basic auth mechanism and create the session. When the html page is returned to the browser after authentication succeeds, it contains a link to 2 static resources. The browser can request these 2 resources in any order it likes, even concurrently. Thus, with SessionHandler.setSessionRenewedOnAuthentication(true), depending on whichever one is serviced first, it will change the sessionid, and thus the second request is likely to see an exception that the sessionids don't match. Note that this is regardless of whether you're using url rewriting or cookies.
If you want all resources to be behind protected urls, then I recommend that you use FORM authentication instead, as the authentication only happens once, and thus the session id change will only happen once.
For those that are interested, the change I'll be making is a small fix to ensure that if no existing session exists at the time of authentication, but is subsequently created before the request is finished being handled (eg the jsp engine creates the session while generating the page), it will be marked by jetty as being a secure session - ie one whose id has never been seen by a client - and thus does not need changing. Without this fix, a session created after authentication would cause a subsequent (re)-authentication to unnecessarily change the id. This primarily affects BASIC authentication, as it is performed on every request.