It's been awhile since I've updated my Indy components. Is there an 
official Indy WebSocket component available yet or plans to produce one? 
I've been looking at RFC 6455 and managed to make a crude Websocket chat 
app using the TidTCPServer component.  What I really want is a component 
that can do both HTTP and Websocket connections simultaneously so that 
the client can do everything through port 80.

By the way, I'm aware of the WebSocket component available from 
www.esegece.com but it does not act as an HTTP server.

I could attempt to expand what I've already done with TidTCPServer and 
make it into an HTTP 1.1 server too. But RFC 2616 is a 176-page document 
and that would be a lot of work, re-inventing what has already been done 
with TidHTTPServer. It would be easier to start with TidHTTPServer and 
try to add WebSocket support to it. Would that even be possible?

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent wrote:

> Is there an official Indy WebSocket component available yet

No.

> plans to produce one?

Not at this time, no.

> It would be easier to start with TidHTTPServer and try to add WebSocket
> support to it. Would that even be possible?

I do not know.  I have never looked at RFC 6455 to see what it actually involves.

--
Remy Lebeau (TeamB)

Remy Lebeau (TeamB) wrote:

> I do not know.  I have never looked at RFC 6455 to see what it actually involves.

Basically the client sends a custom HTTP header with a random key. The 
server responds with a SHA-1 hash of that key. From that point on, 
either side can send data, wrapped in a small data frame with an opcode 
and length indicator. Client data is xor'ed with a 32-bit mask included 
in the frame. Server data is sent unmasked.

This is going to be a big deal in HTML5 for web apps and games. No more 
of that comet/long polling bs to simulate two-way communication. No more 
relying on Flash for a socket connection. WebSockets are already fully 
implemented in FireFox, SeaMonkey, Chrome, Safari, iOS, plus the Android 
versions of FireFox/Chrome. It will also be in IE 10 and the next 
release of Opera.

The protocol was finalized last December. Indy really needs to support 
this to stay relevant, in my opinion.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent wrote:

> Basically the client sends a custom HTTP header with a random key. The
> server responds with a SHA-1 hash of that key. From that point on,
> either side can send data, wrapped in a small data frame with an
> opcode and length indicator.

Inside the TIdHTTPServer.OnCommandGet() event, you can fill in the AResponseInfo 
object as needed with the SHA-1 hash, then call AResponseInfo.WriteHeader() 
(and optionally AResponseInfo.WriteContent() if you have body content to 
send with the response) to manually send the response to the client, then 
run a loop reading/writing frames as needed via the AContext.Connection.IOHandler 
object until a close frame is received or the connection is closed, whichever 
occurs first.  Make sure AResponseInfo.CloseConnection is set to True before 
you exit the event handler (or set TIdHTTPServer.KeepAlive to False) so the 
connection is actually closed on the server end.

--
Remy Lebeau (TeamB)

Remy Lebeau (TeamB) wrote:

> Inside the TIdHTTPServer.OnCommandGet() event, you can fill in the AResponseInfo
> object as needed with the SHA-1 hash, then call AResponseInfo.WriteHeader()
> (and optionally AResponseInfo.WriteContent() if you have body content to
> send with the response) to manually send the response to the client, then
> run a loop reading/writing frames as needed via the AContext.Connection.IOHandler
> object until a close frame is received or the connection is closed, whichever
> occurs first.  Make sure AResponseInfo.CloseConnection is set to True before
> you exit the event handler (or set TIdHTTPServer.KeepAlive to False) so the
> connection is actually closed on the server end.

Thanks, I'll experiment with this and see if I can make it work.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Remy Lebeau (TeamB) wrote:

> Inside the TIdHTTPServer.OnCommandGet() event, you can fill in the AResponseInfo
> object as needed with the SHA-1 hash, then call AResponseInfo.WriteHeader()

Remy,

How do I do this exactly without sending any default headers? Do I use 
CustomHeaders? Here's what I attempted to do:

AResponseInfo.Clear;
with AResponseInfo.CustomHeaders do
begin
   Clear;
   Add('HTTP/1.1 101 Switching Protocols');
   Add('Upgrade: websocket');
   Add('Connection: Upgrade');
   Add('Sec-WebSocket-Accept: ' + SocketHash);
end;
AResponseInfo.WriteHeader;

But what got sent (verified by WireShark) were my headers appended to 
the standard headers and this causes the client to drop the connection:

HTTP/1.1 200 OK
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 0
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: xxxxxx

How do I completely replace the standard headers with my own?

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent Briggs wrote:

> HTTP/1.1 200 OK
> Content-Type: text/html; charset=ISO-8859-1
> Content-Length: 0
> HTTP/1.1 101 Switching Protocols

I figured it out. I just needed to drop the "HTTP/1.1 101 Switching 
Protocols" line and instead just set the response code manually:

AResponseInfo.ResponseNo := 101;
AResponseInfo.ResponseText := 'Switching Protocols';

It still leaves the Content-Type and Content-Length headers in there but 
I guess that's ok because the connection is staying alive now.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent wrote:

> How do I do this exactly without sending any default headers?

What is wrong with sending default headers?  Simply append any extra headers 
you need, let the defaults do the rest for you.

> Do I use CustomHeaders?

Yes.

> Here's what I attempted to do:

Several of those values are handled by other properties instead, eg:

{code:delphi}
AResponseInfo.ResponseNo := 101;
AResponseInfo.ResponseText := 'Switching Protocols';

// note, the CloseConnection property setter also sets the Connection property 
to 'keep-alive'
// so make sure CloseConnection is set, if needed, before you then override 
the Connection
// property with your own value...
AResponseInfo.CloseConnection := False; 
AResponseInfo.Connection := 'Upgrade';

with AResponseInfo.CustomHeaders do
begin
  // use AddValue() instead of Add() so TIdHeaderList can deal with its NameValueSeparator 
property for you...
  AddValue('Upgrade', 'websocket');
  AddValue('Sec-WebSocket-Accept', SocketHash);
end;

AResponseInfo.WriteHeader;
{code}

> But what got sent (verified by WireShark) were my headers
> appended to the standard headers

Because you did not override/utilize the defaults correctly.

--
Remy Lebeau (TeamB)

Kent Briggs wrote:

> I figured it out.

Does that mean you've been successful? I'd like the store the info away
for reference, as I expect I'll be using it some time in the future.

-- 
Dave Nottage [TeamB]

I made a working implementation of Websockets with Indy 10 some time ago:
https://plus.google.com/u/0/110131086673878874356/posts/evicDJLfYtQ

Maybe you can take a look at this? I have tried to make it seperate from the RemObjects part.

Should be nice to have official websockets support in Indy! (based on whatever implementation :) )

Dave Nottage wrote:
> Kent Briggs wrote:
>
>> I figured it out.
>
> Does that mean you've been successful?

Yes, I have a crude working example that will deliver an htm document on 
port 80, which immediately uses javascript to establish a websocket 
connection with the server on the same port. From there I can type 
messages on either side and display on the other. All done with a single 
TIdHTTPServer component.

I will post that code here after I clean it up a bit.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent Briggs wrote:

> I will post that code here after I clean it up a bit.

Ok, I've posted source code for two demos in the 
embarcadero.public.attachments group with the same "Indy WebSockets" 
subject line. The first demo creates a websocket-only connection using 
TIdTCPServer and the second one creates a HTTP+Websocket connection on a 
single port using TIdHTTPServer.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent Briggs wrote:

> Ok, I've posted source code for two demos in the 
> embarcadero.public.attachments group with the same "Indy WebSockets" 
> subject line. The first demo creates a websocket-only connection
> using TIdTCPServer and the second one creates a HTTP+Websocket
> connection on a single port using TIdHTTPServer.

Excellent, thanks!

-- 
Dave Nottage [TeamB]

I wrote:

> Excellent, thanks!

Couple of things:

You had IdHashSHA1 in the uses clause. Was that intentional, or a typo?

It causes an AV on shutdown. I haven't had a look as to where it occurs.

Otherwise, great work, thanks again.

-- 
Dave Nottage [TeamB]

Dave Nottage wrote:

> You had IdHashSHA1 in the uses clause. Was that intentional, or a typo?

It's needed by my HashKey() function. I use Indy's built-in SHA-1 object:

var
   SHA1: TIdHashSHA1;

Which version of Indy do you have?  I think mine is 10.5.6.

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent Briggs wrote:

> It's needed by my HashKey() function. I use Indy's built-in SHA-1
> object:
> 
> var
>    SHA1: TIdHashSHA1;
> 
> Which version of Indy do you have?  I think mine is 10.5.6.

I'm using v10.5.8 to test this. There's IdHashSHA, but not IdHashSHA1.

One other thing: the first send I do from the server (WSock2 project),
causes a 10054 socket error, but the message is still received.
Subsequent sends are OK.

-- 
Dave Nottage [TeamB]

Dave Nottage wrote:

>> Which version of Indy do you have?  I think mine is 10.5.6.
>
> I'm using v10.5.8 to test this. There's IdHashSHA, but not IdHashSHA1.

I seem to have both and either one seems to work ok. They both have a 
2010-09-04 file timestamp. IdHashSHA.pas is 15959 bytes and 
IdHashSHA1.pas is 12819 bytes. Internally they both show "Rev 1.6 
2003-10-12 15:25:50  HHellström".


> One other thing: the first send I do from the server (WSock2 project),
> causes a 10054 socket error, but the message is still received.
> Subsequent sends are OK.

I'm not seeing that. Which browser do you have?

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Dave wrote:

> I'm using v10.5.8 to test this. There's IdHashSHA, but not IdHashSHA1.

Yes, there is an IdHashSHA1 unit, which defines just a TIdHashSHA1 class. 
 There is also an IdHashSHA unit, which also defines a TIdHashSHA1 class, 
but also defines TIdHashSHA224, TIdHashSHA256, TIdHashSHA384, and TIdHashSHA512 
classes as well.  I think the IdHashSHA1 unit got merged into the IdHashSHA 
unit when it was introduced.

> One other thing: the first send I do from the server (WSock2 project),
> causes a 10054 socket error, but the message is still received.
> Subsequent sends are OK.

On the same connection?

--
Remy Lebeau (TeamB)

Dave Nottage wrote:

> One other thing: the first send I do from the server (WSock2 project),
> causes a 10054 socket error, but the message is still received.
> Subsequent sends are OK.

It's probably related to the fact that my send routine is just lazily 
cycling through all the connections and sending the text to all of them. 
Which of course is incorrect, since they all aren't WebSocket 
connections. Especially on Chrome, which seems to make about 6 HTTP 
connections before dropping all the unused ones a few seconds later. 
Although I still can't produce that socket error you are getting.

But anyway, the correct way to do that would be to assign a object to 
each connection's Data pointer and then use that to track a flag showing 
when it has completed the websocket handshake protocol. And only then 
would you attempt to send data to it.

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent Briggs wrote:
> But anyway, the correct way to do that would be to assign a object to
> each connection's Data pointer and then use that to track a flag showing
> when it has completed the websocket handshake protocol. And only then
> would you attempt to send data to it.

A quick fix for that would be to create a global variable:

var
   ReadyToSend: boolean;  // any type will do

Then in OnCommandGet, insert this right after the 
ResponseInfo.WriteHeader line:

AContext.Data := @ReadyToSend;

And then test for that in the SendBtnClick event:

if AC.Data = @ReadyToSend then SendSocketMessage(AC, msg);


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Dave Nottage wrote:

> It causes an AV on shutdown. I haven't had a look as to where it
> occurs.

I've established that it's caused by an attempt to access
ConnectionList after it has been free'd. ConnectionList.Free is called
in FormDestroy, and a subsequent HTTP1Disconnect message occurs which
attempts to access ConnectionList.

-- 
Dave Nottage [TeamB]

Have you already tried my full working websockets yet?
http://asmprofiler.googlecode.com/svn/trunk/-Other-/ROWebsocketsDual/IndyWebsocket/

I made the functionality in a separate IOHandler, and using IdHttp it can handle both http and websockets simultaneous.
AFAIK, I implemented the full rfc spec (multiple frames, close, ping/pong, etc).

For the client side, I made a single read thread which can wait for incoming data for max 64 connection handles
(otherwise you need a read thread per connection, which can end up with lots of threads!)

> {quote:title=andre mussche wrote:}{quote}
> Should be nice to have official websockets support in Indy! (based on whatever implementation :) )

I have been reading the WebSockets spec, and it should not be too difficult to incorporate it into TIdHTTPServer natively (adding it to TIdHTTP would be fairly difficult, so will likely have to create a new TIdWebSocketsClient component instead). I cannot give an ETA right now, but I have added it to our TODO list, so it may or may not end up in a near-future release.

--
Remy Lebeau (TeamB)

> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> I have been reading the WebSockets spec, and it should not be too difficult to incorporate it into TIdHTTPServer natively (adding it to TIdHTTP would be fairly difficult, so will likely have to create a new TIdWebSocketsClient component instead). I cannot give an ETA right now, but I have added it to our TODO list, so it may or may not end up in a near-future release.

Good to hear!

Btw: you can use my code without any license issue, this will probably speed up the implementation (why reinvent the wheel again?) :)
http://asmprofiler.googlecode.com/svn/trunk/-Other-/IndyWebsocketDemo/

Sorry, the server side could only be used with RemObjects.

I have made a seperate HTTP Websocket server without other dependencies, including "your" demo html file:
http://asmprofiler.googlecode.com/svn/trunk/-Other-/IndyWebsocketDemo/

andre mussche wrote:
> Sorry, the server side could only be used with RemObjects.
>
> I have made a seperate HTTP Websocket server without other dependencies, including "your" demo html file:
> http://asmprofiler.googlecode.com/svn/trunk/-Other-/IndyWebsocketDemo/

Your IdServerIOHandlerWebsocket unit is referencing uROIndyHTTPServer, 
which was missing. I commented that out and it compiled Ok. I can't 
figure out how to use your demo, though. It just shows a blank form. I 
can retrieve index.html from 127.0.0.1 but it just shows "Socket closed".

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

> {quote:title=Kent Briggs wrote:}{quote}
> ... I can't 
> figure out how to use your demo, though. It just shows a blank form. I 
> can retrieve index.html from 127.0.0.1 but it just shows "Socket closed".

It is minimal demo: just created new VCL app and added minimal code :).

You probably used something like "http://localost/index.html" to get your WS test page?
That was the only thing you could do with it :).

In Google Chrome it works OK ("socket opened" or something like that), also sending some
text sends it back again to the browser. 
What kind of browser do you use? (IE9 on Win7 doesn't work with your index.html?)

andre mussche wrote:

> You probably used something like "http://localost/index.html" to get your WS test page?

You're missing an "h", but yeah.

> In Google Chrome it works OK ("socket opened" or something like that), also sending some

It works in Chrome and Opera 12.10 Beta. But in FireFox 15.0.1 and 
SeaMonkey 2.12.1 (both share the same Mozilla code), it returns 
immediately with Socket Closed. So something is off in your code. All 
those browsers work with the demos I posted.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

> {quote:title=Kent Briggs wrote:}{quote}
> It works in Chrome and Opera 12.10 Beta. But in FireFox 15.0.1 and 
> SeaMonkey 2.12.1 (both share the same Mozilla code), it returns 
> immediately with Socket Closed. So something is off in your code. All 
> those browsers work with the demos I posted.

Ok, thanks, will look at it tomorrow

> {quote:title=Kent Briggs wrote:}{quote}
> It works in Chrome and Opera 12.10 Beta. But in FireFox 15.0.1 and 
> SeaMonkey 2.12.1 (both share the same Mozilla code), it returns 
> immediately with Socket Closed. So something is off in your code. All 
> those browsers work with the demos I posted.

Firefox uses "keep-alive, upgrade" for the connection field, where I only supported
"upgrade". Is fixed and uploaded to svn now.
Tested with firefox and it works OK.

Hi all,

I am the developer of sgcWebSockets and I have just released a new version of my components, one of the new features is a Server component that supports WebSockets and HTTP requests over the same port (thanks to Kent for his feedback), you can check announce on this thread:

https://forums.embarcadero.com/thread.jspa?threadID=78149

Regards,

Sergio

Kent Briggs wrote:
> Kent Briggs wrote:
>
>> HTTP/1.1 200 OK Content-Type: text/html; charset=ISO-8859-1
>> Content-Length: 0 HTTP/1.1 101 Switching Protocols
>
> I figured it out. I just needed to drop the "HTTP/1.1 101 Switching
> Protocols" line and instead just set the response code manually:
>
> AResponseInfo.ResponseNo := 101; AResponseInfo.ResponseText :=
> 'Switching Protocols';
>
> It still leaves the Content-Type and Content-Length headers in there
> but I guess that's ok because the connection is staying alive now.

Revisiting this thread from last October. I'm just now testing my 
WebSocket code with IE 10. It's only working on my code that uses a 
TCPServer where I build the response header manually. Using my 
HTTPServer code, IE 10 immediately drops the connection with an 
"Incorrect HTTP response error". The only difference is the HTTPServer 
is including these two standard headers:

Content-Type
Content-Length

How can I delete these from the response? I tried doing this:

CustomHeaders.AddValue('Content-Type', '');
CustomHeaders.AddValue('Content-Length', '');

but it had no effect. No other browser has a problem with these two 
headers in the websocket handshake. It's just IE 10, which is apparently 
only looking for the headers mentioned in the spec, and bailing if it 
sees anything else.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent wrote:

> Revisiting this thread from last October. I'm just now testing my
> WebSocket code with IE 10. It's only working on my code that uses a
> TCPServer where I build the response header manually. Using my
> HTTPServer code, IE 10 immediately drops the connection with an
> "Incorrect HTTP response error". The only difference is the HTTPServer
> is including these two standard headers:
> 
> Content-Type
> Content-Length
>
> How can I delete these from the response?

If the Response.ContentType property is a blank string, it gets filled in 
with a default value if the Response.ContentText or Response.ContentStream 
property is assigned a value.  So to omit the "Content-Type" header, set 
the Response.ContentType property to a blank string, and make sure the Response.ContentText 
and Response.ContentStream property are both unassigned.

The Response.ContentLength property can be set to -1 to indicate no value, 
Unfortunately it always gets set to a default to 0 if the Response.ContentText 
and Response.ContentStream are unassigned, so the "Content-Length" header 
cannot be omitted under normal means.

To take full control over what headers get sent and how, you can set the 
Response.HeaderHasBeenWritten property to True before any response has been 
sent, and then write your own headers manually.  You will also have to write 
the status line (response number and response text) manually as well.

> I tried doing this:
> 
> CustomHeaders.AddValue('Content-Type', '');
> CustomHeaders.AddValue('Content-Length', '');
>
> but it had no effect.

Because those values are not stored in the CustomHeaders list to begin with.

> No other browser has a problem with these two headers in the websocket 
handshake.
> It's just IE 10, which is apparently only looking for the headers mentioned 
in the spec,
> and bailing if it sees anything else.

Then IE 10 is broken, and a bug report should be sent to Microsoft.  RFC 
6455 specifically states that "Additional header fields may also be present" 
in the handshake, so the presence of "Content-..." headers should not affect 
the handshake at all, and there is nothing in the RFC that forbids their 
presence.  What is important is only the "Connection", "Upgrade", and "Sec-WebSocket-Accept" 
headers in the server's response, anything else is extra and can be ignored 
by the client if desired.

--
Remy Lebeau (TeamB)

Remy Lebeau (TeamB) wrote:
> Then IE 10 is broken, and a bug report should be sent to Microsoft.  RFC
> 6455 specifically states that "Additional header fields may also be present"
> in the handshake, so the presence of "Content-..." headers should not affect
> the handshake at all

Looks like my problem is elsewhere. Taking those Content- headers out 
did not fix the issue. I can leave those in and get IE 10 to work if I 
load the html file directly from the local file system, which then 
connects to my server on localhost. But if I let my server feed the html 
to IE 10 via localhost, it will not make a websocket connection back to 
the server. The developer tool function inside IE 10 gives this error 
message:

SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 200, OK

The status should indicate 101, not 200. Somehow feeding the html file 
first is affecting this. I can't figure out why. I have no problem 
connecting with FireFox, SeaMonkey, Opera, or Chrome. The Chrome 
debugger will show raw headers and they look like this:

Request URL:ws://127.0.0.1/
Request Method:GET
Status Code:101 Switching Protocols

Request Headers:

GET ws://127.0.0.1/ HTTP/1.1
Pragma: no-cache
Origin: http://127.0.0.1
Host: 127.0.0.1
Sec-WebSocket-Key: E6/Lo/6cfZx11z7+bckLlw==
Upgrade: websocket
Sec-WebSocket-Extensions: x-webkit-deflate-frame
Cache-Control: no-cache
Cookie: NavPageSize=10
Connection: Upgrade
Sec-WebSocket-Version: 13

Response Headers:

HTTP/1.1 101 Switching Protocols
Sec-WebSocket-Accept: aC42wKdrB26RLZFLWIrr+QjkVpk=
Connection: Upgrade
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 0
Upgrade: websocket

Any ideas? I can post my source here.

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent wrote:

> The developer tool function inside IE 10 gives this error message:
> 
> SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code
> 200, OK

Is your HTTP server actually sending status code 200?  If not, then again, 
this looks like an IE bug.

> The Chrome debugger will show raw headers and they look like this:

What does IE's request look like?  You can use Fiddler to see it, if IE's 
own debugger will not.  Or, just have your own HTTP server log the requests 
it receives.

--
Remy Lebeau (TeamB)

Remy Lebeau (TeamB) wrote:

> Is your HTTP server actually sending status code 200?

Not explicitly.

> What does IE's request look like?  You can use Fiddler to see it, if IE's
> own debugger will not.  Or, just have your own HTTP server log the requests
> it receives.

Funny you should mention Fiddler because I've been using that the past 
few hours. And I also have status output on my server that shows all 
connect, disconnect, and onCommandGet activity. When the websocket is 
failing, it's not even sending a request to my server. So this is not a 
server issue. I think it's an IE security issue related to running 
javascript or making ws:// connections on localhost. Although I've got 
that enabled in the Internet Options/Security section.

I can make it work if I do this: load the html file directly from the 
local file system and let it connect to the server. That works. Then 
without closing the browser, I type in 127.0.0.1 in the browser's 
address bar and it will pull the html file from the server and make a 
good websocket connection. However, if I do that in reverse, neither 
method works. I have to close IE, and start with the local file again.

I also tried connecting across different computers inside my LAN. Same 
thing happens, I have to start with a local file. So it's not a 
localhost issue either. I have a Windows VPS with a domain name so I'm 
going to try that next. Maybe it's a raw IP issue.


-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

Kent Briggs wrote:
> I have a Windows VPS with a domain name so I'm
> going to try that next. Maybe it's a raw IP issue.

Nope, that didn't work either.

Today I made another experiment where I use two HTTP server controls, 
one on port 80 that does nothing but serve the html file, and another on 
port 81 that handles the websocket connection. The javascript in the 
html file makes the websocket connection back to port 81. And this works 
in IE 10. So it looks to me like IE 10 won't connect back to the same 
port as the source file (except when I was able to trick it as described 
previously), which of course defeats a major advantage of WebSockets in 
the first place. I've Googled around but can't find anyone else 
complaining about this. I'd like to know if anyone else can replicate 
this problem with IE 10.

-- 
Kent Briggs, kbriggs@briggsoft.com
Briggs Softworks, www.briggsoft.com

André, do you have websocket for C++ Builder 6?