Bug 355945

Comment 1 Leo Jugel 2011-08-26 08:58:35 EDT

Created attachment 202225 [details]
The WebSocket response using 8.0.0.M3

Comment 2 Leo Jugel 2011-08-26 08:59:06 EDT

Created attachment 202226 [details]
The WebSocket response using 8.0.0.RC0

Comment 3 Leo Jugel 2011-08-26 09:00:03 EDT

The images show the response object before sending it back to the client. It was made from the same client with identical code. You can clearly see the difference for the Sec-WebSocket-Origin field.

Comment 4 Leo Jugel 2011-08-26 11:05:18 EDT

I have investigated this a little further. The Implementation for RC0 is probably correct.
However, using CrossOriginFilter and removing the WebSocket check I found that it does not work with Safari either:

1. The filter adds Access-Control-Allow-Origin as the first header which may break D00 compatibility
2. Even adding at the end (modification during debugging) does not lead Safari to use the WebSocket, it still says it is now allowed.

Finally I found that Safari will accept the WebSocket Upgrade only if

Sec-WebSocket-Origin equals the Requests Origin.

Comment 5 Greg Wilkins 2011-08-29 01:11:28 EDT

Simone, 

can you check this issue

Comment 6 Simone Bordet 2011-09-22 11:28:32 EDT

The situation regarding the "Origin" header is still under discussion on the WebSocket expert group at the IETF.

The plan seems to be that WebSocket will comply with CORS regarding cross-origin requests, and therefore the response headers will change again.

Given that WebSocket is still in draft, and that browser support is somehow varying in quality and draft versions, glitches are to be expected.

I just tried Safari 5.1 (Windows) with Jetty 7.5.1, and it can perform a cross origin request without problems.

Given that Jetty 8.0.1 is out (and it has been sync'ed with Jetty 7), can you please give it a try, along with the latest Safari, to see if this issue is still valid ? If it is, then please reopen the bug.

Thanks!

Comment 7 Leo Jugel 2011-09-23 10:28:13 EDT

(In reply to comment #6)
> The situation regarding the "Origin" header is still under discussion on the
> WebSocket expert group at the IETF.
> 
> The plan seems to be that WebSocket will comply with CORS regarding
> cross-origin requests, and therefore the response headers will change again.
> 
> Given that WebSocket is still in draft, and that browser support is somehow
> varying in quality and draft versions, glitches are to be expected.
> 
> I just tried Safari 5.1 (Windows) with Jetty 7.5.1, and it can perform a cross
> origin request without problems.
> 
> Given that Jetty 8.0.1 is out (and it has been sync'ed with Jetty 7), can you
> please give it a try, along with the latest Safari, to see if this issue is
> still valid ? If it is, then please reopen the bug.
> 
> Thanks!

It seems to be complicated. I tried 8.0.1.v20110908 from the maven repo.
The code I use to Suspend is:

@Suspend
def stream = {
  val broadcaster = create new broadcaster
  new Broadcastable("some message", broadcaster)
}

This leads to an IllegalStateException in HttpGenerator.java:241
Not sending "some message" keeps Safari waiting until it breaks the connection and my js code downgrades to streaming.

Leo.

Comment 8 Simone Bordet 2011-09-23 13:31:12 EDT

Leo,

there is too much cooking in your example.

@Suspend is part of a framework ? Which one ? Are you using Groovy ?

Either case, these seems out of scope for this bug.
I do not know what the framework you're using does so I cannot help here.

Do you have evidence that a standard WebSocket request done in plain JavaScript from Safari is failing agains Jetty 8 ?

Thanks!

Comment 9 Leo Jugel 2011-09-23 13:53:34 EDT

Fully understood. Sorry, I did not have much time today, so this was just a first test.
@Suspend is from the atmosphere framework. The code is scala.

Comment 10 Leo Jugel 2011-09-24 15:46:06 EDT

I have tested with the latest SNAPSHOT of atmosphere.
Now it works like a charm with Safari and Chrome. Thanks for your help!