Date: Fri, 29 Mar 2024 06:08:47 +0000 (UTC) Message-ID: <726080211.10905.1711692527371@911f0a1bad02> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_10904_1724580029.1711692527371" ------=_Part_10904_1724580029.1711692527371 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Servoy Application Server exposes several services to the ne= twork it is connected to. Among other they are the following Services:
This chapter discusses the various configuration options in the area of = network connectivity, including the ports over which the services are expos= ed and enabling HTTPS & SSL. The network configuration options for Smar= t Client connectivity comprises the majority of this chapter, as = it is the most extensive.
The Servoy Application Server exposes the majority of it's services over= the so-called HTTP Port (default port 8080). Through= this port the Servoy Admin page, the Web Clients and plugin services are e= xposed to the outside world.
How Smart Clients communicate with the Servoy Application server depends= largely on the chosen configuration. By default the communication goes thr= ough the so-called RMI port (default port 1099), but the S= ervoy Application Server can be configured to tunnel all the communication = over the HTTP port as well, through the so-called Tunnel.<= /p>
While Smart Clients communicate with the Application Server through the = RMI port (or optionally the HTTP Tunnel) while it is running, the Smart Cli= ent is launched over the HTTP port.
All network communication with the Servoy Application Server can be opti= onally secured, by enabling HTTPS for all traffic over the HTTPS port and b= y enabled SSL encryption for the communication between the Smart Client and= the Application Server.
The HTTP port, used to expose many of the services of the Servoy Applica=
tion Server can be configured by editing the server.xml
file l=
ocated in ../application_server/server/conf
. This file contain=
s the following entry by default:
<Connec= tor port=3D"8080" protocol=3D"HTTP/1.1" maxThreads=3D"500" connectionTimeout=3D"60000" redirectPort=3D"8443" useBodyEncodingForURI=3D"true" />=20
By altering the value of the 'port' attribute, for example to 9090 = or 80, the port on which the services of the Servoy Application Server are = exposed can be changed. In order for the changes to go into effect a restar= t of the Application Server is required.
Note that= on some operating systems, like Linux of FreeBSD, binding a process to a p= ort number lower than 1024 (for example the default HTTP port 80) requ= ired the process to run as root or under administrator privileges.
The Tomcat server that underlies the Servoy Application Server can be co= nfigured to support HTTPS. The Tomcat server that comes bundled with Servoy= by default is not setup to support HTTPS, for two reasons:
If direct HTPPS support on the Servoy Application Server is required, it=
can be enabled in Tomcat by adding an additional connector, configured for=
secure access to the server.xml file located in ../application_=
server/server/conf
.
<Connec= tor port=3D"8443" maxThreads=3D"500" connectionTimeout=3D"60000" scheme=3D"https" secure=3D"true" SSLEnabled=3D"true" keystoreFile=3D"conf/keystore" keystorePass=3D"changeit" />=20
In order to create a secure HTTPS connector a keystore with a signed SSL=
Certificate is required. The created keystore needs to be added to the Tom=
cat server installation that is part of the Servoy Application Server, loca=
ted in ../application_server/server
. It's a best practice=
to place the keystore in the {servoyInstall}/application_server/serv=
er/conf/
directory. Note that the same keystore can be used to encry=
pt the traffic between Smart Clients and the Servoy Application Server. See=
SSL Encryption for m=
ore details.
For = more information on how to create a keystore, see Creating a keystor= e with a signed certificate.
Whi= le it's possible to enable SSL without a keystore, this is insecure and bro= wsers will generate security warnings when accessing webpages through HTTPS= in such scenario.
In the definition of the connector above the value of the following = ;attributes need to be adjusted to be correct for the supplied keystor= e:
Additionally, the value of the port attribute needs to be brought in syn= c with the value of the redirectPort attribute of the standard HTTP connect= or (or vise versa), as the redirectPort attribute on the HTTP connector is = used to redirect HTTP traffic to HTTPS when required, see Enforcing HTTPS for all traf= fic. The value for the port can be any value. By default the redirectPo= rt number on the HTTP Connector is set to 8443, but any value, including th= e default HTTPS port 443 is possible.
Note that on some operating systems, like Linux of FreeBSD, binding= a process to a port number lower than 1024 (for example the default HTTPS = port 443) requires the process to run as root or under administrator p= rivileges.
Lastly, to prevent issues with Internet Explorer 8, the Tomcat server ne=
eds to be configured to not add a 'pragma:no-cache' header to all requests.=
To setup Tomcat to not do this, create a file called context.xml in the&nb=
sp;../application_server/server/conf
directory with the follow=
ing content:
<!-- Th= e contents of this file will be loaded for each web application --> <Context> <!-- Default set of monitored resources --> <WatchedResource>WEB-INF/web.xml</WatchedResource> <!-- Uncomment this to disable session persistence across Tomcat restart= s --> <!-- <Manager pathname=3D"" /> --> <Valve className=3D"org.apache.catalina.authenticator.BasicAuthenticator= " disableProxyCaching=3D"false"/> <Valve className=3D"org.apache.catalina.authenticator.NonLoginAuthentica= tor" disableProxyCaching=3D"false"/> <Valve className=3D"org.apache.catalina.authenticator.FormAuthenticator"= disableProxyCaching=3D"false"/> <Valve className=3D"org.apache.catalina.authenticator.DigestAuthenticato= r" disableProxyCaching=3D"false"/> <Valve className=3D"org.apache.catalina.authenticator.SSLAuthenticator" = disableProxyCaching=3D"false"/> </Context>=20
If HTTPS is enabled, it's possible within the Tomcat server underlying t=
he Servoy Application Server to redirect specific or all incoming HTTP traf=
fic to HTTPS by editing the web.xml
file located in ../a=
pplication_server/server/webapps/ROOT/web_inf
.
To redirect all HTTP traffic to HTTP, add the following security-contrai=
nt at the the bottom of the file, just before '</web-app><=
/code>':
<securi= ty-constraint> <web-resource-collection> <web-resource-name>Automatic SLL Forwarding</web-resource-na= me> <url-pattern>/</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>=20
When forcing all HTTP requests to HTTPS, the servoy.jnlpCodebaseOv=
erride
setting needs to be the HTTPS URL (including the HTTPS Connec=
tor port number).
Instead of redirecting all traffic to HTTPS it's also possible to redire= ct only specific traffic to HTTPS or exclude specific traffic. Which traffi= c is redirected or not is controlled by the <url-pattern> and/or <= url-pattern-exclude> nodes of the <web-resource-collection> node o= f the security-constraint.
All url mappings used by Servoy can be found in the file web.xml located=
in ../application_server/server/webapps/ROOT/WEB-INF
=
.
To force HTTPS only on the Servoy Admin page for example the following s= ecurity-constraint ought to be used:
<securi= ty-constraint> <web-resource-collection> <web-resource-name>Automatic SLL Forwarding</web-resource-na= me> <url-pattern>/servoy-admin/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>=20
To force HTTPS on all Web Client traffic and the Servoy Admin page, but = excluding it for Template access, the following security-constraints are to= be used:
<= ;security-constraint> <web-resource-collection> <web-resource-name>Unsecure access</web-resou= rce-name> <url-pattern>/servoy-webclient/templates/*</u= rl-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>NONE</transport-guarante= e> </user-data-constraint> </security-constraint> <security-constraint> <web-resource-collection> <web-resource-name>Automatic SLL Forwarding</= web-resource-name> <url-pattern>/servoy-admin/*</url-pattern> <url-pattern>/servoy-webclient/*</url-pattern> <url-pattern>/servoy-webclient</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-= guarantee> </user-data-constraint> </security-constraint>=20
The network configuration options for Smart Clients are quite extensive = and which configuration to choose is largely dependent on the (differe= nt) network setups between the Servoy Application Server and the = machines on which Smart Clients are launched. Determining the most optimal = network configuration for Smart Client comes down to answering the followin= g questions:
The answers to these questions could eliminate one or more of the four p= ossible Connection Modes, the the matrix below:
|
Direct Connection |
Two-Way Socket |
HTTP Tunnel |
Socket Tunnel |
---|---|---|---|---|
Client machines require direct access to the = Application Server's HTTP port |
=20
|
=20
|
=20
|
=20
|
Client machines require direct access to= the Application Server's RMI port |
=20
|
=20
|
=20
|
=20
|
Application Server requires direct access to = all ports on each client machine |
=20
|
=20
|
=20
|
=20
|
Supports client machines with Web Start proxy= configuration |
=20
|
=20
1
|
=20
|
=20
|
Supports multiple IP addresses for the Applic= ation Server |
=20
|
=20
|
=20
|
=20
|
1 Two-Way socket mode cannot initialize properl= y if Java WebStart on the Client machine is configured to use a Proxy. When= it fails to initialize, the Smart Client will fall back to Direct Connecti= on mode. See 'Two-Way socket mode' under Connection Modes below for more details.
The Servoy Application Server has several modes in which Smart Clients c= an communicate with the Application Server. Which mode is the best depends = on the network setup between the Servoy Application Server and the client m= achines on which the Smart Client will be launched. As the Servoy Smart Cli= ent runs over both a LAN and WAN's, including over the internet, it can be = that there are different network setups for different client machines. = ;
Two-Way socket
Two-Way socket mode provides a robust communication mechanism between Sm= art Clients and the Servoy Application Server, where only the Smart Client = initiates connections to the Application Server over the RMI port. This mea= ns that only the Smart Clients need to be able to access the Application Se= rver and that the Application Server does not need to be able to connect to= the client machine, like is required when using Direct Connection mode. However, in case Java WebStart on the clien= t machine is configured to connect through a proxy, Servoy will not be able= to instantiate Two-Way socket and thus falls back to the Direct Connection= mode, with the restrictions that come with Direct Connection mode. It is p= ossible to configure Java WebStart on each client machine to not use a prox= y, but this needs to be done on each individual machine and might conflict = with other Java WebStart applications that do require the proxy settings. I= f this happens then on the client the java preferences > network setting= s need to be changed, so that the proxy settings are configured as 'direct = connection' instead of 'use browser'. Better is to use one of the tunnels b= elow.
Within individual Smart Clients it's possible to turn off Two-Way socket= through Preferences. When the user does so, the Smart Client will start to= use Direct Connection. The Smart Client will error if the network criteria= for Direct Connection mode to work are not met.
Note that disabling Two-way socket mode on the Application Server is pus= hed to all Smart Client, but when re-enabling Two-way socket on the Applica= tion server, this setting is NOT pushed to the Smart Clients. The user need= s to manually enable TwoWay socket under Preferences in the Smart Client ag= ain.
Tunnel
Servoy comes with a so-called tunnel that Smart Clients can use to conne= ct to Application Server. The tunnel is a more robust communication mode, a= t the cost of utilization of more server-side resources. For each Smart Cli= ent more memory, threads and sockets (connections) are used on the Applicat= ion Server. The tunnel supports two modes, namely HTTP and Socket which can= be used exclusively or mixed through the use of Profiles. Of the two tunne= l modes, the HTTP mode consumes most serverside resources.
HTTP Tunnel
When us= ing the tunnel in HTTP mode, all communication between the Smart Client and= the Application Server is done using the HTTP Protocol, over the HTTP port= on which the Application Server runs. The benefit of this mode is that it = doesn't require that the client machines can access the Application Server = on the RMI port. This can be a huge benefit in cases where it's not possibl= e to open up access to the RMI port. When Smart Clients connect to the Appl= ication Server using the HTTP Tunnel, they will utilize threads and connect= ions from the Tomcat application server that underlies the Servoy Applicati= on Server.
Socket Tunnel
The tunnel in Socket mode is similar to the tunnel in= HTTP mode, except that the communication with the Application Server goes = over the RMI port of the Application Server. This means that the RMI port o= f the Application Server should be accessible from all client machines that= will run Smart Clients. Unlike the tunnel in HTTP mode, the tunnel in Sock= et mode uses server-side resources (threads & sockets (connections)) di= rectly in Servoy, not through Tomcat.
The overview below indicated the difference in used resources per Connec= tion mode. This information is provided in case tuning is required for larg= e scale deployments. For example, by default the Tomcat HTTP/HTTPS connecto= rs are configured to allow a maximum of 500 concurrent threads. When deploy= ing large numbers of Smart Clients over the HTTP tunnel (possible in combin= ation with a large number of Web Clients), it might be required to change t= he maximum allowed threads in the Tomcat connectors.
Connection Mode |
Used Threads |
Used sockets |
---|---|---|
Two-Way socket |
1 thread per concurrent request |
1 per request + 2 per client |
HTTP Tunnel |
2 Tomcat and 2 non-tomcat threads per client<= /p> |
2 per client |
Socket Tunnel |
2 threads per client |
1 per client |
All connection modes can be configured through the Servoy Admin page, un= der Network Settings.
This can be done by the property: SocketFactory.tunnelConnect=
ionMode
4 options can there be set: http, socket,http&socket and 2waysocket.=
The preferred way is http&socket, this means that both http tunnel a= nd socket tunnel are enabled, by default a client will then connect in sock= et mode but you can have a profile so that the client will start in http mo= de.
Two-Way socket
SocketFactory.useSSL: set to true 1
SocketFactory.co= mpress: set to trueIf the server on which the Servoy Application Server runs has multiple n= etwork interfaces through which Smart Clients ought to connect:
j= ava.rmi.server.hostname: set to the IP address of the server's loopback int= erface, usually 127.0.0.1
Tunnel
SocketFactory.useSSL: set to true 1
SocketFactory.co= mpress: set to trueSocketFactory.tunnelUseSSLForHttp: set to false if tomcat is configured = in https else true, see SSL Encryption
1: SSL can also be turned off, but for security reasons it is= advised to have SSL Encryption turned on when possible.See SSL Encryption for additio= nal settings.
With all connection modes, except the HTTP Tunnel, the Smart Clients com= municate with the Servoy Application Server over the so-called RMI port. Th= is port needs to be accessible from all the client machines at all times, t= hus cannot be blocked by firewalls.
Through configuration the RMI Start Port value can be set. When the Serv= oy Application Server is launched it tries to bind to the specified RMI Sta= rt port. If it fails to bind to this port, it will automatically try to bin= d to the next port. This process will continue until the binding succeeds. = The actually used RMI port should never be blocked by any firewall in = between the Servoy Application Server and the client machines.
The RMI port number that is actually used is shown under Server = Information in the Servoy Server Status on the Se= rvoy Admin page under Servoy Server Home
The RMI Start port can be set through the Servoy Admin page under
The meaning of the RMI Server Hostname setting (java.rmi.server.ho=
stname
) depends on the Connection Mode used:
Connection Mode |
Relevance |
---|---|
Two-Way Socket |
When the machine of which the Servoy Applicat= ion Server runs has multiple network interfaces on which the Smart Clients = could connect, this setting needs to be set to the IP address of the server= 's loopback interface (usually 127.0.0.1) |
HTTP/Socket Tunnel |
no relevance |
If a host= name is specified, note that the hostname is resolved to an IP address on t= he server!
The RMI Connection timeout setting (rmi.connection.timeout) controls how= long a the RMI layer will hang on to open sockets for reuse. A high value = can lead to many open sockets.
If there are a high number of open sockets, it can happen that a network= component like a Firewall or NAT Router automatically starts closing them.= When this happens, when Servoy tries to use the socket connection, it will= error. Servoy will automatically remove the erroneous socket and try = the next one. This will cause a slight performance decrease.
By lowering the RMI Connection timeout value, the total number of o= pen sockets will be reduced, preventing the network component from closing = them automatically.
Value |
Comment |
---|---|
120 |
Default value |
10 ~ 15 |
Alternative value to bring down the number of= open sockets, to prevent the network component form automatically closing = them |
0 |
When set to 0, the system default will be use= d |
The Ping Delay setting (ApplicationServer.pingDelay) provides a mechanis= m to prevent network components from closing open connections that are inac= tive for a while.
When set too high, and a network component between the Application Serve= r and the Smart Client closes the connection, the User will be presented wi= th a Connection Lost dialog, from which the user can choose to reconnect or= close the Smart Client.
When experiencing intermittent Connection Lost dialogs in the Smart Clie= nt, lower the ping delay.
When using the HTTP Tunnel exclusively for connecting Sma=
rt Clients, the alternative HTTP tunnel KEEP_ALIVE_INTERVAL can be use=
d instead, as this option has a lower overhead than the ApplicationSe=
rver.pingDelay
setting. The ApplicationServer.pingDelay
=
can be set to a very high number in this case.
A Profile is a named set of settings that can be used by a Smart Client.=
Profiles are a way to allow the definition of multiple sets of configura= tions that are used by groups of Smart Clients. For more information on Pro= files, see Profiles.
All the communication between the Servoy Application Server and the Smar=
t Clients can be encrypted using SSL Keys and certificates. Servoy Smart Cl=
ients can only work with either a 3rd party signed certificates or without =
a certificate. Self signed certificates are not supported by default, but c=
an be made to work by adding the setting SocketFactory.useTestSSL to either a Profile that is used or to the system.properties (
When SSL is enabled it will also encrypt all properties in the servo= y.properties file that have a property key that contains the text 'pas= sword'. For the encryption the specified SSL certificate will be used (or a= default certificate if no keystore with certificates is specified). This m= eans that if the certificate/keystore is changed or SSL is disabled, the pa= sswords cannot be decrypted anymore and have to be manually set again in pl= ain text in the servoy.properties file. If the encrypted properties a= re not reset manually, the Servoy Application Server will fail to launch.&n= bsp;
Enabling SSL Encryption for communication between Smart Clients and the = Servoy Application Server requires a keystore with a signed SSL certificate= and the adjustment of a three settings on the Servoy Admin page. For = more information on how to create a keystore, see Creating a keystor= e with a signed certificate .
The created keystore needs to be added to the Servoy Application Server =
installation. Best practice is to place the keystore in the ../application_server/server/conf
directory. In this location =
the keystore is then also available to the Tomcat server underlying the Ser=
voy Application Server and thus the same certificate can also be used for s=
erving HTTPS content (see Enabling HTTPS).
After making the keystore available to the Servoy Application Server, th= e Servoy Application Server needs to be told where the keystore can be foun= d and configured to use it. The relevant settings are exposed under the Net= work Settings on the Servoy Admin page:
../application_server/
), for example serve=
r/conf/mykeystore.ks
Note that SSL can also be enabled without specifying the keystore, by ju=
st setting SocketFactory.useSSL
to true. This is cons=
idered insecure and should only be used for testing/demo purposes.
Compression reduces the amount of data send back and forth between the S= ervoy Application Server and the Smart Clients, thus improving performance.=
The Compression setting can be administered through the Servoy Admin pag= e, under Network Settings > Socke= tFactory.compress. Compression is turned on by default and should = always be on. It should only be disabled when experiencing connection issue= s due to compression.
In many scenario's there will be proxies in between the Smart Client and= the Application Server. Depending on the connection mode through which the= Smart Client connects and the configuration of Java WebStart on the client= machine, this will either not be an issue at all, or require some configur= ation or will not work.
Proxy configuration can be done in Java WebStart on the client machine. =
Connection mode |
Proxy Supported? |
Config |
Comments |
||
---|---|---|---|---|---|
Two-Way Socket |
No |
N/A |
Two-way socket communication cannot be instan=
tiated by the Smart Client inside Java WebStart if Java WebStart is configu=
red to run through a proxy. |
||
HTTP Tunnel |
Yes |
Not required by default |
It's possible to explicitly specify the proxy= url, username and password, through Advanced HTTP Tunnel configuration | ||
Socket Tunnel |
Yes |
|
No configuration required |
|
|
Note: up = to and including Servoy 5.2.8 it is required to manually set the following = system property on the Application Server to get the best possible: SocketF= actory.useProxySelector=3Dtrue. As of Servoy 5.2.9 and Servoy 6.0 this sett= ing with be done by default
In the HTTP Tunnel connection mode, all communication between the Smart = Client and the Servoy Application Server is done through the HTTP protocol = and as such is susceptible to the influences of network components and= /or processes that handle the HTTP traffic. Such influences can be anti-vir= us software, firewalls, proxies, NAT routers etc. While all these infl= uences in general serve a goal, they can pose a challenge when trying = to establish a reliable connection between the Smart Client and the Applica= tion Server.
The negative influences that these network components and/or processes c= an cause are, at a high level, summarized below.
HTTP Chunked mode & Buffering
The HTTP protocol allows for the sending of HTTP requests in small chunk= s, instead of the entire request at once. As there is significant overhead = on the instantiation of HTTP requests, utilizing the chunked modus to send = a package of data as a chunk of a larger HTTP request instead of instantiat= ing an HTTP request for each package of data provides a way to limit the ov= erhead of HTTP request instantiation.
However, some components in a network connection that deal with HTTP tra= ffic perform buffering. This is the the process of holding onto individual = chunks of the HTTP requests until the entire request is received,= before sending the full request to the next component in the network conne= ction. This means that the individual chunks only reach their destination w= hen all the chunks that belong to an individual HTTP request are received.&= nbsp;
Connection timeouts
Components in the network connection over which an HTTP request is execu= ted might inflict a limit on how long the connection may be open, before it= is automatically closed.
Content-Length enforcement
The HTTP protocol contains a mechanism to indicate the length of an HTTP= request. While is not common practice to check the supplied leng= th with the actual length and reject the request if those do not match, it = can be that there are components in the network connection between the Smar= t Client and Application Server that do perform such a check and reject the= HTTP requests if the numbers do not match.
Additionally some components in the network might have a maximum content= length that they enforce.
In everyday life, buffering is the most likely candidate to cause issues= , thus by default the HTTP tunnel is configured to NOT use Chunked mode, at= the cost of performance. The HTTP Tunnel is also configured by default wit= h values for the relevant settings to prevent Connection timeout issues in = most scenario's. In the area of content length enforcement, the maximum len= gth for HTTP requests is set to a proper value. The enforcing of the actual= content length being the same as the specified content length is NOT done,= as the likelihood of network connections enforcing this not that= great, while enabling this would result in significant performance degrada= tion.
The configuration of the HTTP tunnel can be altered by adding the releva= nt settings as system properties through the Servoy Admin page, under = Servoy Server Home > Admin settings > system.properties. It's also possible= to expose different configurations through Profiles.
The following settings are available:
Property |
Default Value |
Description |
---|---|---|
system.property.com.sebster.tunnel.http.clien= t.closeRequestOnFlush |
true |
Whether or not to close the HTTP Request afte=
r each package of data. Default is true. While this incurs a significant ov=
erhead due to having to instantiate an HTTP request for each package of dat=
a, this does prevent buffering issues. |
system.property.com.sebster.tunnel.http.clien= t.chunked |
true |
Whether or not to send data packages as chunk= s of a larger HTTP Request. This setting has no effect if closeRequest= OnFlush is set to true. Chunked mode is the preferred mode of operation, bu= t susceptible to buffering issues. |
system.property.com.sebster.tunnel.http.clien= t.keepAliveInterval |
15 |
The interval (in seconds) with which a little= data is send into the HTTP request to prevent it from being terminated by = the network due to inactivity. Lower when experiencing connection timeout i= ssues. |
system.property.com.sebster.tunnel.http.clien= t.maxRequestAge |
300 |
The maximum time (in seconds) that a HTTP req= uest is kept alive. Lower when experiencing timeout issues. |
system.property.com.sebster.tunnel.http.clien= t.contentLength |
2097152 b |
The maximum length of a single HTTP Request. = Lower only when the network enforces a lower limit |
system.property.com.sebster.tunnel.http.clien= t.strictContentLength |
false |
If set to true, the actual length of each HTT= P request will be made to match the contentLength setting, by appendin= g dummy data. Only set to true if the Content-Length is enforced by th= e network, as it incurs a significant performance penalty |
system.property.com.sebster.tunnel.http.clien= t.proxyUri |
|
In case the Smart Client needs to communicate= through a specific proxy and the proxy configuration cannot be done in Jav= a WebStart, the proxy url can be set directly on the HTTP Tunnel. |
system.property.com.sebster.tunnel.http.clien=
t.proxyUsername, |
|
Proxy credentials. If required by the proxy a= nd not set here, the Smart Client will provide the user with a dialog to en= ter the credentials |
system.property.com.sebster.tunnel.http.clien= t.userAgent |
|
Empty by default. Can be set to any value if = it is required to send a specific user-agent string with each HTTP request<= /p> |
The HTTP tunnel is already configured for most reliable connectivity, so= this does not require a Profile. A relevant Profile would be the performan= ce Profile, which basically means enabling Chunked mode, by disabling 'clos= eRequestOnFlush'
system.pro= perty.com.sebster.tunnel.http.client.CLOSE_REQUEST_ON_FLUSH=3Dfalse= =20
Note that the e= xample above assume that the HTTP tunnel is already enabled. See Profiles for more info.
Servoy supports Kerebos authentication for Smart Clients, as Java WebSta= rt supports Kerebos authentication. Setting up Kerebos authentication withi= n Java WebStart on the client machine will not be described in the Servoy d= ocumentation, as it's highly specific and requires detailed knowledge of Ke= rebos configuration.
If Kerebos authentication support is required, the following setting set= s up required authentication context within Servoy: system.property.servoy.= usejaas=3Dtrue. This setting can be applied through the Servoy Admin page, = under Servoy Server Home > Admin = settings > system.properties or = can be applied through a specific Profile.
For the configuration of Java WebStart on the client machines, please co= ntact a Kerebos specialist.
Kerebos authent= ication is currently not supported in combination with the HTTP and Socket = Tunnel