Apache Tomcat 8 (8.5.49) - WebSocket How-To Apache Tomcat 8 Version 8.5.49, Nov 17 2019 Links Docs Home FAQ User Comments User Guide 1) Introduction 2) Setup 3) First webapp 4) Deployer 5) Manager 6) Host Manager 7) Realms and AAA 8) Security Manager 9) JNDI Resources 10) JDBC DataSources 11) Classloading 12) JSPs 13) SSL/TLS 14) SSI 15) CGI 16) Proxy Support 17) MBeans Descriptors 18) Default Servlet 19) Clustering 20) Load Balancer 21) Connectors 22) Monitoring and Management 23) Logging 24) APR/Native 25) Virtual Hosting 26) Advanced IO 27) Additional Components 28) Mavenized 29) Security Considerations 30) Windows Service 31) Windows Authentication 32) Tomcat's JDBC Pool 33) WebSocket 34) Rewrite Reference Release Notes Configuration Tomcat Javadocs Servlet 4.0 Javadocs JSP 2.3 Javadocs EL 3.0 Javadocs WebSocket 1.1 Javadocs JASPIC 1.1 Javadocs Common Annotations 1.2 Javadocs JK 1.2 Documentation Apache Tomcat Development Building Changelog Status Developers Architecture Functional Specs. Tribes WebSocket How-To Table of Contents Overview Application development Tomcat WebSocket specific configuration Overview Tomcat provides support for WebSocket as defined by RFC 6455. Application development Tomcat implements the Java WebSocket 1.1 API defined by JSR-356. There are several example applications that demonstrate how the WebSocket API can be used. You will need to look at both the client side HTML and the server side code. Tomcat WebSocket specific configuration Tomcat provides a number of Tomcat specific configuration options for WebSocket. It is anticipated that these will be absorbed into the WebSocket specification over time. The write timeout used when sending WebSocket messages in blocking mode defaults to 20000 milliseconds (20 seconds). This may be changed by setting the property org.apache.tomcat.websocket.BLOCKING_SEND_TIMEOUT in the user properties collection attached to the WebSocket session. The value assigned to this property should be a Long and represents the timeout to use in milliseconds. For an infinite timeout, use -1. If the application does not define a MessageHandler.Partial for incoming binary messages, any incoming binary messages must be buffered so the entire message can be delivered in a single call to the registered MessageHandler.Whole for binary messages. The default buffer size for binary messages is 8192 bytes. This may be changed for a web application by setting the servlet context initialization parameter org.apache.tomcat.websocket.binaryBufferSize to the desired value in bytes. If the application does not define a MessageHandler.Partial for incoming text messages, any incoming text messages must be buffered so the entire message can be delivered in a single call to the registered MessageHandler.Whole for text messages. The default buffer size for text messages is 8192 bytes. This may be changed for a web application by setting the servlet context initialization parameter org.apache.tomcat.websocket.textBufferSize to the desired value in bytes. The Java WebSocket specification 1.0 does not permit programmatic deployment after the first endpoint has started a WebSocket handshake. By default, Tomcat continues to permit additional programmatic deployment. This behavior is controlled by the org.apache.tomcat.websocket.noAddAfterHandshake servlet context initialization parameter. The default may be changed by setting the org.apache.tomcat.websocket.STRICT_SPEC_COMPLIANCE system property to true but any explicit setting on the servlet context will always take priority. When using the WebSocket client to connect to server endpoints, the timeout for IO operations while establishing the connection is controlled by the userProperties of the provided javax.websocket.ClientEndpointConfig. The property is org.apache.tomcat.websocket.IO_TIMEOUT_MS and is the timeout as a String in milliseconds. The default is 5000 (5 seconds). When using the WebSocket client to connect to secure server endpoints, the client SSL configuration is controlled by the userProperties of the provided javax.websocket.ClientEndpointConfig. The following user properties are supported: org.apache.tomcat.websocket.SSL_CONTEXT org.apache.tomcat.websocket.SSL_PROTOCOLS org.apache.tomcat.websocket.SSL_TRUSTSTORE org.apache.tomcat.websocket.SSL_TRUSTSTORE_PWD The default truststore password is changeit. If the org.apache.tomcat.websocket.SSL_CONTEXT property is set then the org.apache.tomcat.websocket.SSL_TRUSTSTORE and org.apache.tomcat.websocket.SSL_TRUSTSTORE_PWD properties will be ignored. For secure server end points, host name verification is enabled by default. To bypass this verification (not recommended), it is necessary to provide a custom SSLContext via the org.apache.tomcat.websocket.SSL_CONTEXT user property. The custom SSLContext must be configured with a custom TrustManager that extends javax.net.ssl.X509ExtendedTrustManager. The desired verification (or lack of verification) can then be controlled by appropriate implementations of the individual abstract methods. When using the WebSocket client to connect to server endpoints, the number of HTTP redirects that the client will follow is controlled by the userProperties of the provided javax.websocket.ClientEndpointConfig. The property is org.apache.tomcat.websocket.MAX_REDIRECTIONS. The default value is 20. Redirection support can be disabled by configuring a value of zero. Comments Notice: This comments section collects your suggestions on improving documentation for Apache Tomcat. If you have trouble and need help, read Find Help page and ask your question on the tomcat-users mailing list. Do not ask such questions here. This is not a Q&A section. The Apache Comments System is explained here. Comments may be removed by our moderators if they are either implemented or considered invalid/off-topic. Copyright © 1999-2019, The Apache Software Foundation
