I could not reproduce the issue with Chrome 6.0.447.0 dev on Windows Vista. I sniffed the packets and I've got something like:

GET /websocket/tests/simple HTTP/1.1
Upgrade: WebSocket
Connection: Upgrade
Host: ******
Origin: ******
Sec-WebSocket-Key1: 598191 8^1 2
Sec-WebSocket-Key2: 3 2-1 - 4#  836YC %6o   3~ @F K6"

~..h.`.y

Where the last 8 characters are binary. This sounds legitimate to me.

Could you try again with the newest dev version? It should send random keys like above, not a constant such as "!0" or 8 bytes of "\0".

Thank you for testing.
I tested with Chrome 6.0.447.0 dev on Windows Vista.

And I found that you can reproduce this bug to do new WebSocket() in Worker.

regards.

Aha, I didn't know it was in a Worker. Will look into it.

Sorry for poor information.Thanks!!

Confirmed.

This issue occurs only on Windows.

The source of failure is:
- Call to rand_s (in WebCore::randomNumber) fails due to sandbox, and it always returns 0.
- generateWebSocketKey might insert a space to front of the key string, which is clearly prohibited in WebSocket spec.

We need the following fixes:
(a) Fix generateWebSocketKey,
(b) Make randomNumber check the return value of rand_s() and fall back to rand() if necessary, and
(c) Allow worker process to call rand_s (probably RtlGenRandom API).

(a) and (b) require changes to WebKit and are not difficult. I have no idea of how to do (c) for now.

Upstream bug filed: https://bugs.webkit.org/show_bug.cgi?id=41327

upstream bug says fixed. so marking this fixed.

Well, it is not actually fixed. I need to make a Chromium-side change, too, and I'm writing a layout test for it.

ah ok apologies. i will move it to m6. will you be able to finish it by the m6 deadline?

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53027 

------------------------------------------------------------------------
r53027 | yutak@chromium.org | 2010-07-20 02:25:23 -0700 (Tue, 20 Jul 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/worker/worker_main.cc?r1=53027&r2=53026
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/worker/worker_uitest.cc?r1=53027&r2=53026

Call rand_s() in a worker process before entering the sandbox.

We need to do it to cause advapi32.dll to load the sandbox is turned on.
Otherwise rand_s() will fail in the sandbox.

BUG=47390
TEST=Run "ui_tests --gtest_filter=WorkerTest.WorkerWebSocketLayoutTests".

Review URL: http://codereview.chromium.org/2799047
------------------------------------------------------------------------

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=55555 

------------------------------------------------------------------------
r55555 | yutak@chromium.org | 2010-08-10 03:37:43 -0700 (Tue, 10 Aug 2010) | 12 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/worker/worker_main.cc?r1=55555&r2=55554
   M http://src.chromium.org/viewvc/chrome/branches/472/src/chrome/worker/worker_uitest.cc?r1=55555&r2=55554

Merge 53027 - Call rand_s() in a worker process before entering the sandbox.

We need to do it to cause advapi32.dll to load the sandbox is turned on.
Otherwise rand_s() will fail in the sandbox.

BUG=47390
TEST=Run "ui_tests --gtest_filter=WorkerTest.WorkerWebSocketLayoutTests".

Review URL: http://codereview.chromium.org/2799047

TBR=yutak@chromium.org
Review URL: http://codereview.chromium.org/3119003
------------------------------------------------------------------------

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)