ealize that was significantly
different from X509ExtendedTrustManager. Looks like it's working now,
thanks!
On Fri, May 26, 2023 at 3:24 AM Mark Thomas wrote:
> On 25/05/2023 22:52, V User wrote:
>
> > The how-to on websockets (
> > https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html)
On 25/05/2023 22:52, V User wrote:
The how-to on websockets (
https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html) says that
you can bypass hostname verification with a custom TrustManager: "For
secure server endpoints, host name verification is enabled by default. To
b
e would be to update all our
servers to have certificates with proper SANs and make our
application initiate websockets using hostnames that match the SANs, but
that will take some time to do and I'm trying to figure out if there's a
workaround that will let us complete the upgrade to Tomcat 9
On 30/06/2022 11:56, Jürgen Weber wrote:
Hi,
use case: HTML clients connect to @ServerEndpoint, some Servlet.GET
should send a message to connected HTML clients.
I found no other way to have the Servlet have a reference to the
ServerEndpoint than a hack with a static field, as in the Tomcat
Hi,
use case: HTML clients connect to @ServerEndpoint, some Servlet.GET
should send a message to connected HTML clients.
I found no other way to have the Servlet have a reference to the
ServerEndpoint than a hack with a static field, as in the Tomcat
sample.
Sridar,
On 7/28/21 20:16, Sridhar Rao wrote:
We are using the tomcat8.5 app nodes behind an Nginx Load Balancer.
Whenever the LB takes out an app node from the pool, "existing" WebSocket
connections are still staying with the app node. Also, if a new app node is
added to the pool, WS
Hi All,
We are using the tomcat8.5 app nodes behind an Nginx Load Balancer.
Whenever the LB takes out an app node from the pool, "existing" WebSocket
connections are still staying with the app node. Also, if a new app node is
added to the pool, WS connections are not load balanced as they are
On Wed, Oct 9, 2019, 18:11 Gary Sheppard wrote:
> On Tue, Jun 12, 2018 at 12:13 Mark Thomas wrote:
>
> >> It would be very useful to be able to configure this, so if you are
> >> going to patch the code, please make this configurable by the client.
> >> See HttpsURLConnection.setHostnameVerifier
On Tue, Jun 12, 2018 at 12:13 Mark Thomas wrote:
>> It would be very useful to be able to configure this, so if you are
>> going to patch the code, please make this configurable by the client.
>> See HttpsURLConnection.setHostnameVerifier
>>
>> I think it's appropriate to simply match that API
On 31/07/2019 04:37, Kirill Ilyukhin wrote:
> Hello Mark,
>
> Please let me disagree with you. I have connected JVisualVM to Tomcat JVM,
> run the test with 10,000 connections, performed several explicit GCs and
> made a heap dump. All 10,000 WsSessions are in heap. They are referenced as
>
Hello Mark,
Please let me disagree with you. I have connected JVisualVM to Tomcat JVM,
run the test with 10,000 connections, performed several explicit GCs and
made a heap dump. All 10,000 WsSessions are in heap. They are referenced as
following:
this
<- wsSession - class:
On 30/07/2019 05:48, Kirill Ilyukhin wrote:
> Hello Mark,
>
> Please see the test case and Tomcat JVM heap dump screenshot attached.
> For sake of simplicity I do Thread.sleep() in client code instead of
> reading bytes from server.
That test case does not demonstrate a memory leak in either
Hello Mark,
Please see the test case and Tomcat JVM heap dump screenshot attached.
For sake of simplicity I do Thread.sleep() in client code instead of
reading bytes from server.
Test configuration is the following:
Server version:Apache Tomcat/8.5.3
Server built: Jun 9 2016
On 26/07/2019 10:33, Kirill Ilyukhin wrote:
> Hello,
>
> When Tomcat receives WebSocket text message with invalid UTF-8, it closes
> this connection with NOT_CONSISTENT reason. But after that some objects
> (WsSession, UpgradeHandler, etc) stay in heap forever. They are referenced
> from
Hello,
When Tomcat receives WebSocket text message with invalid UTF-8, it closes
this connection with NOT_CONSISTENT reason. But after that some objects
(WsSession, UpgradeHandler, etc) stay in heap forever. They are referenced
from AbstractProtocol's connections map.
This leak consistently
Your idea of wrapping the interface returned by the registry was a stroke
of brilliance! And I'm pleased to say it was successful.
I'm now working to resolve another small hiccup. The IoC registry can be
configured to provide the service as either a singleton or a new instance
for each new
Hmm.
Looking at this some more I'm not sure this is going to work.
HarbourServerEndpoint needs to extend javax.websocket.Endpoint which it
can't do as an interface.
I think you are going to have to wrap the instance returned by the
registry. In which case you can probably go back to using POJO.
So I've converted the server endpoint from annotation-based to
programmatic, to get around the constraint of the @ServerEndpoint
annotation having to decorate a concrete class. The elements of this
annotation now occupy an implementation of ServerApplicationConfig:
public class
Thanks Mark, you've made it clear that annotating the interface is not an
option.
Converting my server endpoint from annotation based to programmatic is not
a problem, nor is implementing ServerApplicationConfig to configure what
were previously @ServerEndpoint elements: value, encoders,
anding of the WebSocket
> library.
It won't work. From the Java WebSockets specification:
4.1
@ServerEndpoint
This class level annotation signifies that the Java class it decorates
must be deployed by the implementation as a websocket server endpoint
and made available in the URI-space of the webso
Hi Mark,
Looking at the Tapestry-IoC Registry code I notice that although it
constructs a (plastic) service proxy object, it does cast it to its
associated interface before making it available from the registry's
getService() method. So if I move the WebSocket annotations to my
interface as
Based on what you wrote regarding WebSocket annotations not following Java
inheritance, I imagine the below wouldn't work either.
public class MyServerEndpointConfig extends ServerEndpointConfig {
@Override
public Class getEndpointClass() {
return MyServiceInterface.class;
}
> The custom Configurator looks fine. The problem is with trying to do
> this with a POJO endpoint. There is an underlying assumption that - for
> a POJO endpoint - the endpoints will will instances of the POJO class.
> This doesn't seem to hold in your case so hence it breaks.
>
> The WebSocket
On 17/04/2019 22:58, Christopher Dodunski wrote:
> Hello,
>
> Just a quick question with regard to extending
> ServerEndpointConfig.Configurator to override Tomcat's default action of
> instantiating the POJO class annotated with @ServerEndpoint on receiving a
> WebSocket request. My reason for
Hello,
Just a quick question with regard to extending
ServerEndpointConfig.Configurator to override Tomcat's default action of
instantiating the POJO class annotated with @ServerEndpoint on receiving a
WebSocket request. My reason for doing this is that my endpoint class
depends on IoC
Just to clarify, both services being injected the IoC way are developed by
me as part of the core program, so nothing sinister to be concerned about.
What would be useful to know is whether Tomcat instantiates classes
annotated with @ServerEndpoint inside or outside of the context of the WAR
app
Hi John,
The server-side endpoint is itself implemented as a Tapestry 'service',
allowing it to be injected into other application classes for pushing
messages out to connected clients. Whereas the service injected into the
endpoint class itself allows the endpoint to query this service when a
IoC - *shudders*
Can't this be used to "inject" mass surveillance into J2E apps? It
was curiously missing in the bullet items down the home page of
tapestry. :p
So, you're expecting to inject dependencies into components
instantiated on a websocket?
By "the rest of the application" below, are
Hi team,
I have developed a web application using the Apache Tapestry framework and
deployed on Apache Tomcat. The application also supports WebSocket
connections with desktop clent applications. Following the advice of the
Tapestry community, I included the server-side endpoint within the
On 07/02/2019 00:31, Jesse Schulman wrote:
> Is it possible for tomcat to run with HTTP2 and WebSockets on the same
> connector? I have tried configuring it myself and looked for examples
> without success.
This works out of the box.
I have confirmed the behaviour with my local build
ort in
> which the app can access tomcat for websockets directly. We've not been
> able to get this to work over httpd.
> John
>
>
> On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman
> wrote:
>
> > Is it possible for tomcat to run with HTTP2 and WebSockets on the same
> &g
I am interested in this too. Basically we've had to set another port in
which the app can access tomcat for websockets directly. We've not been
able to get this to work over httpd.
John
On Wed, Feb 6, 2019 at 5:32 PM Jesse Schulman wrote:
> Is it possible for tomcat to run with HT
Is it possible for tomcat to run with HTTP2 and WebSockets on the same
connector? I have tried configuring it myself and looked for examples
without success.
Thanks!
Jesse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Shawn,
On 10/16/18 00:00, Shawn Heisey wrote:
> On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
>> I have several webapps that do a significant amount of recursive
>> loads of snippits of HTML utilizing XHR/http/ajax requests. These
>> apps are all
On 10/15/2018 9:16 PM, Jerry Malcolm wrote:
I have several webapps that do a significant amount of recursive loads
of snippits of HTML utilizing XHR/http/ajax requests. These apps are
all debugged and in production. The server has no problem whatsoever
in keeping up with the multiple
limits on the browsers that block more than 6 concurrent
connections to a server is killing me in performance.
I've been looking into WebSockets which I understand does not incur the
wrath of the browsers when I have a need for more than 6 concurrent
connections. I have no problem making
*client* API ?
Yes, the client API is part of the websockets EE specification. Initially,
Tomcat had just enough to implement the requirements of the specification,
so it was unusable in practice (users were supposed to use another client,
such as Tyrus which is now donated to Jakarta - feels nice
On Tue, Jun 12, 2018 at 7:05 PM André Warnier (tomcat)
wrote:
> This is a bit OT, but I have a question since the beginning of this thread
> :
> Is Tomcat really supposed to provide a websocket *client* API ?
>
Yes, the client API is part of the websockets EE specification. Initi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 6/12/18 1:06 PM, André Warnier (tomcat) wrote:
> On 12.06.2018 18:13, Mark Thomas wrote: [snip]..
>>
>> I'll see what I can do. The major constraint is that all this has
>> to be set via Tomcat specific user properties as there is no API
On 12.06.2018 18:13, Mark Thomas wrote:
[snip]..
I'll see what I can do. The major constraint is that all this has to be set via
Tomcat
specific user properties as there is no API for in the Java WebSocket API.
This is a bit OT, but I have a question since the beginning of this thread :
Is
On 12/06/2018 16:12, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 6/11/18 10:31 AM, Mark Thomas wrote:
On 11/06/18 11:47, Weiner Harald wrote:
What are your thoughts?
I'm leaning towards adding:
SSLParameters sslParams = new SSLParameters();
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 6/11/18 10:31 AM, Mark Thomas wrote:
> On 11/06/18 11:47, Weiner Harald wrote:
>
>
>
>> What are your thoughts?
>
> I'm leaning towards adding:
>
> SSLParameters sslParams = new SSLParameters();
>
On 11/06/18 11:47, Weiner Harald wrote:
> What are your thoughts?
I'm leaning towards adding:
SSLParameters sslParams = new SSLParameters();
sslParams.setEndpointIdentificationAlgorithm("HTTPS");
sslSocket.setSSLParameters(sslParams);
unconditionally to WsWebSocketContainer.createSSLEngine()
Hello Tomcat user group,
I want a Tomcat-Servlet to connect to a secure web socket endpoint to exchange
data with another component / server
(so my Tomcat-Servlet is acting as a WebSocket client).
Now I would also like to do some hostname verification (verify that the host to
which I am
aders Tomcat depends on to identify the request as a WebSocket
> request. Can you use tcpdump to capture a request that returns a 404?
> Looking at that trace should point us in the right direction.
>
> Mark
>
thx mark
thats very likely it.
https://aws.amazon.com/elasticloadbal
i checked they are on all
> the reques tthen.
>
> This seems to work for all kind of connections to servlets/files/filters
> and so on except websockets
> Suddenly if we switch that on then all the websocket connections are
> returning 404 (i see that in the browser a
/files/filters
and so on except websockets
Suddenly if we switch that on then all the websocket connections are
returning 404 (i see that in the browser and in the tomcat access log)
Can't find any other thing in the log files that would give me a clue what
is happening
Does anybody has an idea why
omcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
> >> Atmosphere Websockets.
> >>
> >> We have had reports of sessions logging out while users are
> >> active with our Vaadin-based application. This has been
> >> frustrating as we can't seem to track
On 09/08/17 17:46, Christopher Schultz wrote:
> Websocket ignoramus, here. Is there a way for (websocket) application
> code on the server side to trigger a "touch" of the HttpSession that
> is linked with the connection? Or is the problem that the websocket
> connection and the HTTP connection
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 8/9/17 11:35 AM, Mark Thomas wrote:
> On 09/08/17 16:09, David Wall wrote:
>> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
>> Atmosphere Websockets.
>>
>> We have had reports of sessi
On 8/9/17 8:35 AM, Mark Thomas wrote:
On 09/08/17 16:09, David Wall wrote:
We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
Atmosphere Websockets.
We have had reports of sessions logging out while users are active with
our Vaadin-based application. This has been frustrating
On 09/08/17 16:09, David Wall wrote:
> We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
> Atmosphere Websockets.
>
> We have had reports of sessions logging out while users are active with
> our Vaadin-based application. This has been frustrating as we can't
>
We're using Tomcat 8.5.16 with Java 1.8.0_91, Vaadin 7.7.10 and
Atmosphere Websockets.
We have had reports of sessions logging out while users are active with
our Vaadin-based application. This has been frustrating as we can't
seem to track down why Tomcat's session is not being updated
oh finally you resolved the problem with websockets when is closed... when
i told you 2 years ago ... i didnt hear me
he time out happens a new websocket connection is coming in
(with the above url) then we quickly re attach the session object to that
new endpoint and it will go on
only after a while if there is no new websocket being setup, we invalidate
the session object (and then we could also invalidate the h
On 31/05/17 08:38, Johan Compagner wrote:
>>
>>
>> It depends. If the URL in the HTTP UPGRADE request includes the session
>> ID, and that session ID is still valid in ##1, then the WebSocket
>> request will be handled by ##1.
>>
>> Mark
>>
>>
> would a feature request be accepted for this that
>
>
> It depends. If the URL in the HTTP UPGRADE request includes the session
> ID, and that session ID is still valid in ##1, then the WebSocket
> request will be handled by ##1.
>
> Mark
>
>
would a feature request be accepted for this that there can be a cookie set
where that "load balancer"
messages on reconnections.
Hope this helps.
Ludovic
Le 30 mai 2017 12:40:45 GMT+02:00, Johan Compagner <jcompag...@servoy.com> a
écrit :
>>
>> > But now i have websockets, if i connect to ##1 first and i have the
>end
>> > point there
>> > Then i add a ##
>
> > But now i have websockets, if i connect to ##1 first and i have the end
> > point there
> > Then i add a ##2 version of the context
> > then i guess a new user that opens a websocket will go to ##2
> > but if the existing user does a refresh in the browser
this is jsessionid?
>
> So a refresh in the browser or another request with the jsessionid will go
> to the version it started with i guess?
>
> But now i have websockets, if i connect to ##1 first and i have the end
> point there
> Then i add a ##2 version of the context
>
id will go
to the version it started with i guess?
But now i have websockets, if i connect to ##1 first and i have the end
point there
Then i add a ##2 version of the context
then i guess a new user that opens a websocket will go to ##2
but if the existing user does a refresh in the browser then it will als
On 18/07/2016 16:25, l.pe...@senat.fr wrote:
> Hi.
>
> I am using Tomcat 8.0.36 with Atmosphere 2.4.5 (
> https://github.com/Atmosphere/atmosphere ) to implement WebSockets with
> fallbacks such as long polling.
Can you reproduce this without Atmosphere? If not, that suggests an
On 18/07/2016 16:25, l.pe...@senat.fr wrote:
Hi.
I am using Tomcat 8.0.36 with Atmosphere 2.4.5 (
https://github.com/Atmosphere/atmosphere ) to implement WebSockets
with fallbacks such as long polling.
I am writing tests using Tomcat JSR356 implementation.
I studied your WebSocket samples
Hi.
I am using Tomcat 8.0.36 with Atmosphere 2.4.5 (
https://github.com/Atmosphere/atmosphere ) to implement WebSockets with
fallbacks such as long polling.
I am writing tests using Tomcat JSR356 implementation.
I studied your WebSocket samples and I am using a fake trustore
Hi!
I have developed an app using websocket. I am using servers to upload my app in
DigitalOcean but here the websockets doesnt work but using another server
server4U everuthing is fine. I am using Tomcat 8.5.3 somebody has any cluee,
any, about this behavour , the only thing that I think
are served.
At poking around with the WebSockets I had a hard time to figure out if the
HTML was wrong or if the server just didn't serve the Endpoint.
So basically for debugging reasons.
mf
2016-07-03 18:57 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 03/07/2016 11:04, Martin Funk wrot
On 03/07/2016 11:04, Martin Funk wrote:
> Hi,
>
> I'm into my first steps of using the WebSocket API.
> Things are quite nice so far, WebSockets, used the right way, might open up
> a complete new type of WebApplications.
>
> I've got a question though, is there a wa
Hi,
I'm into my first steps of using the WebSocket API.
Things are quite nice so far, WebSockets, used the right way, might open up
a complete new type of WebApplications.
I've got a question though, is there a way to configure Tomcat to announce
the annotated ServerEndpoints, it comes across
I am running Tomcat 8.0.33. In my webapp I need to make outbound
websocket connections (i.e. be a client endpoint) through a HTTP proxy.
Outbound encrypted websockets (wss://foo.bar) work fine, but
unencrypted ones (ws://foo.bar) fail.
What I am seeing
On 05/04/2016 19:48, Mark Thomas wrote:
> On 04/04/2016 18:01, Francesco Bassi wrote:
>> Hello everybody.
>>
>> Tomcat 9 has a different behaviour than Tomcat 8, during the management of
>> MessageHandler.onMessage:
>>
>> - in Tomcat 8:
>> Thread.currentThread().getContextClassLoader() returns
On 04/04/2016 18:01, Francesco Bassi wrote:
> Hello everybody.
>
> Tomcat 9 has a different behaviour than Tomcat 8, during the management of
> MessageHandler.onMessage:
>
> - in Tomcat 8:
> Thread.currentThread().getContextClassLoader() returns an instance of
>
Hello everybody.
Tomcat 9 has a different behaviour than Tomcat 8, during the management of
MessageHandler.onMessage:
- in Tomcat 8:
Thread.currentThread().getContextClassLoader() returns an instance of
org.apache.catalina.loader.WebappClassLoader
- in Tomcat 9
...@apache.org:
On 22/03/2014 16:17, Cyril Auburtin wrote:
Hi, this issue concerns the tomcat-embed server, (likely also the normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented
also the
normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
and noticed it from my project
From: Cyril Auburtin [mailto:cyril.aubur...@gmail.com]
Subject: Re: [Bug 56301] Websockets not working after 8.0.0-RC10
Tomcat 8.0.0-RC10 is the stable version or is it 8.0.3?
No version of Tomcat 8 has been released as stable. Look here:
http://tomcat.apache.org/whichversion.html
, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html)
and noticed it from my project https://github.com/n11/mongo-cli-java
Hi, this issue concerns the tomcat-embed server, (likely also the normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http://www.oracle.com/technetwork/articles/java/jsr356
On 22/03/2014 16:17, Cyril Auburtin wrote:
Hi, this issue concerns the tomcat-embed server, (likely also the normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http
, Cyril Auburtin wrote:
Hi, this issue concerns the tomcat-embed server, (likely also the normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http://www.oracle.com
-embed server, (likely also the
normal
tomcat server)
after version 8.0.1, websockets can't be estblished like before.
I tried from a simple websocket example (standard java websocket
implemented in tomcat8
http://www.oracle.com/technetwork/articles/java/jsr356-1937161.html
Tomcat 7.0.52 on Ubuntu 14.04
Websocket connection closes automatically after about 10 seconds. The
browser creates the initial connection. OnOpen is called on the server.
After 10 seconds OnClose is called and the connection is closed.
I have tried changing connectionTimeout=-1 on Connector.
Ubuntu 13.04 and Tomcat 8
Same issue. Client makes the connection fine. Tomcat closes the connection
in 10 seconds.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bob,
On 3/4/14, 1:15 PM, Bob Mancarella wrote:
Ubuntu 13.04 and Tomcat 8
Same issue. Client makes the connection fine. Tomcat closes the
connection in 10 seconds.
What's the client timeout on the server side? Perhaps you are...
timing out.
-
Besides what I mentioned where would i find that?
On Tue, Mar 4, 2014 at 1:54 PM, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bob,
On 3/4/14, 1:15 PM, Bob Mancarella wrote:
Ubuntu 13.04 and Tomcat 8
Same issue. Client
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bob,
On 3/4/14, 11:16 AM, Bob Mancarella wrote:
Tomcat 7.0.52 on Ubuntu 14.04
Websocket connection closes automatically after about 10 seconds.
The browser creates the initial connection. OnOpen is called on the
server. After 10 seconds
Just using the EchoAnnotation code
///
// client code
sorry, target is actually
target = 'ws://' + window.location.host +
'/inlook/websocket/echoAnnotationhttp://connect.ws/
';
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bob,
On 3/4/14, 2:39 PM, Bob Mancarella wrote:
Just using the EchoAnnotation code
More info.
This is the return code to the browser
1006CLOSE_ABNORMAL*Reserved.* Used to indicate that a connection was closed
abnormally (that is, with no close frame being sent) when a status code is
expected.
On Tue, Mar 4, 2014 at 2:41 PM, Bob Mancarella bobm...@gmail.com wrote:
sorry,
Thats the strange thing. The code isnt doing anything. It connects,
receives the onopen message and then the onclose with the 1006 return code
within a few seconds.
On Tue, Mar 4, 2014 at 3:04 PM, Bob Mancarella bobm...@gmail.com wrote:
More info.
This is the return code to the browser
On 04/03/2014 16:16, Bob Mancarella wrote:
Tomcat 7.0.52 on Ubuntu 14.04
Websocket connection closes automatically after about 10 seconds. The
browser creates the initial connection. OnOpen is called on the server.
After 10 seconds OnClose is called and the connection is closed.
I have
JSR356
OK, this is strange. If I go here http://www.websocket.org/echo.html
I get the same results. Click on Connect but don't hit Send and I get a
Disconnected message soon after.
If I use TLS it seems to work. If I hit Send immediately after Connect it
seems to work.
Anyone else seeing this?
On
On 04/03/2014 20:36, Bob Mancarella wrote:
OK, this is strange. If I go here http://www.websocket.org/echo.html
I get the same results. Click on Connect but don't hit Send and I get a
Disconnected message soon after.
If I use TLS it seems to work. If I hit Send immediately after Connect it
could you try this.
http://dev.bizunite.com/inlook/echo.html
click on annotation API then Connect and see if you stay connected.
On Tue, Mar 4, 2014 at 3:44 PM, Mark Thomas ma...@apache.org wrote:
On 04/03/2014 20:36, Bob Mancarella wrote:
OK, this is strange. If I go here
On 3/4/2014 3:46 PM, Bob Mancarella wrote:
could you try this.
http://dev.bizunite.com/inlook/echo.html
click on annotation API then Connect and see if you stay connected.
Seems to be working fine for me.
On Tue, Mar 4, 2014 at 3:44 PM, Mark Thomas ma...@apache.org wrote:
On 04/03/2014
On 04/03/2014 20:50, David kerber wrote:
On 3/4/2014 3:46 PM, Bob Mancarella wrote:
could you try this.
http://dev.bizunite.com/inlook/echo.html
click on annotation API then Connect and see if you stay connected.
Seems to be working fine for me.
I get an immediate close with the
Ugh. Looks like I need to use wss in my environment. I just found this.
If an encrypted WebSocket Secure connection (wss://) is used, then in the
case of transparent proxy servers, the browser is unaware of the proxy
server, so no HTTPCONNECT is sent. However, since the wire traffic is
encrypted,
I didn't implement programmatic.
On Tue, Mar 4, 2014 at 3:52 PM, Mark Thomas ma...@apache.org wrote:
On 04/03/2014 20:50, David kerber wrote:
On 3/4/2014 3:46 PM, Bob Mancarella wrote:
could you try this.
http://dev.bizunite.com/inlook/echo.html
click on annotation API then Connect
);
// this code gets the JarScanner and sets scanClassPath to false:
// with this setting the websockets are not deployed
Container[] containers =
tomcat.getService().getContainer().findChildren();
StandardHost host = (StandardHost)containers[0];
containers
1 - 100 of 217 matches
Mail list logo
