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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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]
![]() |
0 |
![]() |
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 :) )
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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]
![]() |
0 |
![]() |
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]
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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]
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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]
![]() |
0 |
![]() |
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!)
![]() |
0 |
![]() |
> {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)
![]() |
0 |
![]() |
> {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/
![]() |
0 |
![]() |
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/
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
> {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?)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
> {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
![]() |
0 |
![]() |
> {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.
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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)
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
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
![]() |
0 |
![]() |
André, do you have websocket for C++ Builder 6?
![]() |
0 |
![]() |