Table of Contents
This document explains how to deploy proxied OpenLaszlo applications with the OpenLaszlo Server. If you deploy your applications SOLO, that is, not proxied by the OpenLaszlo Server, you do not need to read this chapter.
An OpenLaszlo application is the set of LZX files and accompanying art assets and data files that are used by that application. The easiest way to package these files is to use the Developer's Console. Clicking on the Server button in the Developer's Console opens an HTML page with complete documentation to guide you through the process. See ??? in the Developer's Guide for a complete description.
The OpenLaszlo Server is a set of 100% pure Java classes (along with some configuration files) that can be used to develop and deploy OpenLaszlo applications inside Java servlet containers/application servers. OpenLaszlo application deployers need to know a few details about Java servlet containers/application servers. This document reviews these details and then goes on to explain how to deploy proxied OpenLaszlo applications with OpenLaszlo Server.
Once a proxied OpenLaszlo application has been developed, for users other than the developer to have access to it, it must be deployed. OpenLaszlo applications are deployed inside Java servlet containers/application servers. The steps include:
Develop a Laszlo application
Choose, install, and configure a servlet container for deployment.
Create a web application including the OpenLaszlo application and OpenLaszlo Server software.
Configure the OpenLaszlo Server
Monitor OpenLaszlo Server activity
Bundles the Jakarta Tomcat Servlet Container
Includes a Java web application archive (WAR) that is pre-configured for OpenLaszlo applications.
Requires just a few simple installation steps.
Includes a Java web application archive (WAR) directory that is pre-configured for OpenLaszlo applications.
Requires that you have a Java servlet container or application server that supports at least 2.3 of the Java servlet specification.
The same installation can be used to both develop and deploy an OpenLaszlo application. Alternatively, you may use a separate installation to deploy your OpenLaszlo applications.
Conventions used in the remainder of this document:
We use $INSTALLDIR as the directory in which you installed the OpenLaszlo Server.
When file or directory path names are provided, unless
otherwise noted, we use the Unix convention for the separator
character--the forward slash ('
/'). To translate
the documentation for use on Windows systems, simply replace
every instance of '
/' with a '
A quick note on terminology: The terms servlet container and application server are often used interchangeably. OpenLaszlo documentation tends to prefer the term servlet container because it is more specific and accurate. The term application server is less standard but, in general, it is used to describe Java server software that usually is actually a servlet container. Also, any J2EE application server is, by the definition given in the J2EE specification, a servlet container. In general, the OpenLaszlo Server requires that a servlet container/application server support at least version 2.3 of the Java servlet specification.
The OpenLaszlo Server comes with the Jakarta Tomcat servlet container, which can be used to deploy OpenLaszlo applications. There are several other servlet containers on the market today. Laszlo does not endorse any specific servlet containers. See the public Laszlo website for the latest list of supported containers. Information on how to choose a and configure a servlet container is beyond the scope of this document, but deployers should note that performance of a servlet container (and underlying JVM) can have a significant impact on OpenLaszlo Server performance.
Once you have chosen and installed a servlet container, you may need to adjust some of its default configuration settings. In particular, you may need to configure the default TCP/IP port and secure (SSL/https) TCP/IP port. You may also need to configure the container's JVM settings like the initial and maximum heap sizes (see below) and the default and maximum number of threads.
Some servlet containers may also be configured with web servers like the Apache HTTPD web server sitting in front of them. The precise details for how to set up configurations like this, as well as the how to adjust the settings mentioned above are beyond the scope of this document; see your servlet container documentation for details. However, see below for more details on which parameters you may need to set.
For best results, you may need to change your servelet container's compression settings, especially for DHTML applications.
You can use an internet search engine using a phrase gzip followed by your server, e.g. 'gzip tomcat'. For example, here's
You can set the heap sizes via the
line options such
which will set both the initial heap size to 256 MBytes and maximum heap sizes to 512 MBytes. See your servlet container documentation, in particular, for where to place this setting.
Note that the DNS hostname of the computer running the servlet
container as well as the TCP/IP port(s) on which it listens will surface
as part of the URL that will be used to access your OpenLaszlo application
when it is deployed. In the remainder of this document, we will use the
and port number
to indicate the values of these
To run the OpenLaszlo Server you must have the Java SDK (sometimes called the JDK, J2SDK, or J2SE SDK), not just the JRE, version 1.4 or greater. It's available at http://java.sun.com/j2se/1.4.2/download.html (click the Download J2SE SDK link).
Mac OSX users do not have to install the SDK, as it is installed with OSX by default.
The name for the directory structure that houses OpenLaszlo applications within a servlet container is called, confusingly, a Java web application, or often simply a webapp. Webapps are sometimes packaged as single files that are called web application archive (WAR) files.
The LPS (standard) distribution comes with an OpenLaszlo-enabled webapp directory pre-installed in Tomcat. The web application directory is
This webapp includes sample Laszlo applications, example LZX files, tutorials, and documentation. The LPS Core distribution comes with a copy of this Laszlo-enabled webapp for you to install into your own servlet container. The directory version of this webapp is
Note that the name of the webapp surfaces as part of the URL used to access your Laszlo applications. We will use the string $webapp below to indicate the name of a deployed web application.
For more details on Java web applications and WAR files, see the Sun documentation on servlets.
To create an empty OpenLaszlo-enabled webapp, you simply create a new directory and copy in the WEB-INF directory from the lps-5.0.x webapp. On a UNIX system, do
mkdir myappcp -r $LPS-WEBAPPDIR/WEB-INF myappcp -r $LPS-WEBAPPDIR/lps myapp
where $LPS-WEBAPPDIR is the path to a copy of the lps-5.0.x web application. For LPS (standard) distribution, $LPS-WEBAPPDIR is $INSTALLDIR/Server/lps-5.0.x.
To place your Laszlo applications inside myapp, copy the LZX (.lzx extension) files and art assets for your Laszlo application(s) inside the myapp directory.
To deploy the webapp, follow your servlet container's instructions.
Note that the lps-5.0.x webapp that is packaged with LPS comes pre-configured for development, not deployment. Before deploying your applications you will need to reconfigure the OpenLaszlo Server for deployment, as explained in the next section.
The OpenLaszlo Server comes with several assets, such as documentation and examples, that you may not need or want to deploy with your OpenLaszlo application. To create a minimal deployment configuration: (For LPS 2.2 and later).
clear the OpenLaszlo Server caches and server logs (or stop server and remove caches/logs and restart server)
compile your applications
Now you can safely remove everything under the webapp except the WEB-INF directory and the lps directory. keeping only:
You should also remove
as it includes the source code viewer jsp and other unneeded utilities.
The OpenLaszlo Server comes preconfigured for use as a development platform. There are a number of configurable settings that affect the Server performance and security that should be set properly when deploying OpenLaszlo applications. You can see a sample deployment configuration in $WEBAPP/WEB-INF/lps/config-deploy
By default, the OpenLaszlo proxy server ships "wide open". See the discussion of security, below. See also the section on white listing and black listing for instructions on how to change this default behavior.
The files that are used to configure the OpenLaszlo Server are:
$WEBAPP/WEB-INF/web.xml - Java web application configuration
$WEBAPP/WEB-INF/lps/config/lps.properties - OpenLaszlo Server configuration properties
$WEBAPP/WEB-INF/lps/config/lps.xml - OpenLaszlo Server log configuration and filters for data requests and user-agents.
$WEBAPP/WEB-INF/lps/config/lzusers.xml - User database for default OpenLaszlo Server security servlet
$WEBAPP/WEB-INF/lps/config/crossdomain.xml - Sample Cross Domain Policy file for applications that need runtime HTTPS access.
Changing settings in any of these files will require that the OpenLaszlo-enabled web application be restarted. See your servlet container documentation for instructions on how to restart. For the OpenLaszlo (standard) distribution, you can simply stop and re-start Tomcat.
This file is used to configure the webapp that houses OpenLaszlo applications as well as the main OpenLaszlo servlet.
<servlet> <servlet-name>LPS</servlet-name> <servlet-class>org.openlaszlo.servlets.LZServlet</servlet-class> </servlet>
There should be a servlet mapping that maps all .lzx files to this servlet like:
<servlet-mapping> <servlet-name>LPS</servlet-name> <url-pattern>*.lzx</url-pattern> </servlet-mapping>
There are also other settings you can make here that affect the authentication scheme used by the OpenLaszlo Server to authenticate use of the OpenLaszlo Server's persistent connection feature. See ??? for more details.
This file contains numerous settings that affect LPS operation. Below is the lps.properties file that ships with LPS.
#=============================================================================== # LPS properties file for development #=============================================================================== # * P_LZ_COPYRIGHT_BEGIN ****************************************************** # * Copyright 2001-2008 Laszlo Systems, Inc. All Rights Reserved. * # * Use is subject to license terms. * # * P_LZ_COPYRIGHT_END ******************************************************** #=============================================================================== # Default request type for naked .lzx requests (requests with no (or unknown) lzt # query string). For development, you want 'app_console'. For deployment, you # want 'html'. #defaultRequestType=html defaultRequestType=app_console #=============================================================================== # Request toggles - many of these should be set to false # for deployment. allowRequestXML=true allowRequestINFO=true allowRequestSOURCE=true allowRequestFILTER=true # The following requests will require the admin. password if set below allowRequestCLEARCACHE=true allowRequestCLEARLOG=true allowRequestLOG=true allowRequestLOGCONFIG=true allowRequestGC=true allowRequestCACHEINFO=true allowRequestSETCACHESIZE=true allowRequestSERVERINFO=true allowRequestERRORCOUNT=true allowRequestSTAT=true allowRequestCONNECTIONINFO=true allowRequestJAVARPCINFO=true allowRequestSOAPINFO=true allowRequestXMLRPCINFO=true #=============================================================================== # Allow forced recompile (will require admin password if reset) allowRecompile=true #=============================================================================== # Uncomment for stat (default is true) and url collection (default is false) #collectStat=true #dataRequest.collectURL=true #mediaRequest.collectURL=true #=============================================================================== # Password to check for administrative requests. # Uncomment and admin requests will require this passwd in the query # string as ?pwd=your_passwd_here #adminPassword=SET_ME_PLEASE #=============================================================================== ## Backend http properties # #http.maxConns=1000 #http.maxConnsPerHost=1000 # The number of redirects to try (security issue; default is 0) http.followRedirects=3 # Timeout for back-end http requests #http.backendTimeout=30000 #http.backendConnectionTimeout=30000 #=============================================================================== # Compilation manager dependency options: # # never - compile once # check - check all includes # always - compile for each access # # 'never' results in highest performance, requires an ?lzrecompile=true request # to recompile the application. compMgrDependencyOption=check #=============================================================================== # Cache settings # # Locations of cache directories # The default location is inside the WEB-INF/lps/work directory # of your web application. # Compilation cache #cache.directory=WEB-INF/lps/work/cache # Compilation media cache #cmcache.directory=WEB-INF/lps/work/cache/cmcache # Script compiler cache #scache.directory=WEB-INF/lps/work/scache # Runtime Media cache #mcache.directory=WEB-INF/lps/work/mcache # Runtime Data cache #dcache.directory=WEB-INF/lps/work/dcache # Cache sizes (0 = disabled (or allow 1 item for disk caches), -1 means infinite) # Defaults are 500000000 for disk and 1000000 for mem #mcache.disk.size=500000000 #mcache.mem.size=1000000 # Max size allowable for an item to be cached in memory # in the media cache (some media files are big and we # need to keep them on disk only). mcache.mem.item.max=1000000 # Cache sizes (0 = disabled (or allow 1 item for disk caches), -1 means infinite) # Defaults are 500000000 for disk and 1000000 for mem #dcache.disk.size=500000000 #dcache.mem.size=1000000 # Compiler Media Cache # there is no need to keep any of these files in memory cmcache.mem.size=0 # Keeps script cache small scache.disk.size=10000000 scache.mem.size=1000000 #=============================================================================== # Apache AXIS settings # Defaults to WEB-INF/lps/config/client-config.wsdd # axis.clientConfigFile=client-config.wsdd #=============================================================================== # WSDL load options: # # never - loads once # always - loads for each access # # 'never' results in highest performance rpc.soap.wsdlLoadOption=always #=============================================================================== # Persistent connection properties maxMessageLen=2000 connectionLength=65536 #=============================================================================== #=============================================================================== # Compiler parameters compiler.runtime.default=swf8
In general, when you go to deploy an OpenLaszlo application, you may
wish to disable certain request types. The OpenLaszlo Server supports numerous
request types that are indicated via the
string variable in an URL. You can specify the default request type
for URLs that don't specify
?lzt via the
Table 3.1. Request Types
|Property||Request type||LPS Response when enabled|
|allowRequestXML||?lzt=xml||XML for the LZX application source|
|allowRequestINFO||?lzt=info||Information about compiled LZX application|
|allowRequestSOURCE||?lzt=source||Allows or prevents download of LZx source|
|(debugging)||?lzt=debug||HTML wrapper for LZX source code Debugger|
|allowRequestFILTER||?lzt=filter||Filter for dynamic HTML wrapper|
|allowRequestCLEARCACHE||?lzt=clearcache||Clears all server caches|
|allowRequestLOG||?lzt=log||Responds with the current detailed log|
|allowRequestLOGCONFIG||?lzt=logconfig||Displays and sets log configuration|
|allowRequestCLEARLOG||?lzt=clearlog||Clears the current log|
|allowRequestCACHEINFO||?lzt=cacheinfo||Gets media cache information|
|allowRequestSERVERINFO||?lzt=serverinfo||Gets LPS information|
|allowRequestERRORCOUNT||?lzt=errorcount||Gets LPS error count|
|allowRequestSTAT||?lzt=stat||Gets LPS statistics when enabled|
|allowRequestGC||?lzt=gc||Runs the garbage collector|
|allowRequestCONNECTIONINFO||?lzt=connectioninfo||Gets information on persistent connection|
There are three values for this property:
compile an LZX application on each request.
compile the LZX application if it or any of its source files or assets have changed since the application was last compiled.
compile the LZX application only if there is no cached version. This results in highest server performance but requires server restarts to pick up any application changes.
In general, deployments where the LZX source files and assets are
fixed should use
never. For deployments where LZX source
and/or art assets may change, you should use
check. If you
never and need to update the application, you may
lzrecompile=true query string at the end
of a request for the application. You may also need to provide the administrator
password for this to take affect.
The server maintains an in-memory cache of recently compiled script segments. In general, the default value of 100 should suffice. Under rare circumstances, when deployed Laszlo application will be edited, recompiled frequently, or generated automatically via a pre-processing request, you may want to increase the size of this cache.
The server uses several caches that are maintained via a standard LRU (least recently used) algorithm. Each caches can be configured independently and each one can be set to use disk only or memory (backed by disk) plus additional disk space. The caches (and their names) are:
Table 3.2. Server Caches
||runtime XML data|
||statically compiled media|
In general, it helps to know the expected number and size of the items being cached to optimally tune some of these numbers. Here's the list:
Table 3.3. Server cache configuration
||max size in bytes for disk cache||
||max size in bytes for RAM cache||
Same as above except
||max size in bytes for an in memory item|
||initial map capacity|
||initial map capacity|
is one of
Note that the amount of disk space a cache will use is actually
. Also note that the cache will does not
keep track of the amount of disk space used for meta data. For
smaller items, the meta data can be significant.
Each cache has two properties that affect its performance:
initial capacity (
mapsize) and load factor
load). The capacity is the number of buckets
in a hash table, and the initial capacity is simply the capacity at
the time the hash table is created. The load factor is a
measure of how full the hash table is allowed to get before its
capacity is automatically increased. When the number of entries in
the hash table exceeds the product of the load factor and the current
capacity, the capacity is roughly doubled by calling the
As a general rule, the default load factor (
offers a good tradeoff between time and space costs. Higher values
decrease the space overhead but increase the lookup cost (reflected in
most of the operations of the
expected number of entries in the map and its load factor should be
taken into account when setting its initial capacity, so as to
minimize the number of
rehash() operations. If the
initial capacity is greater than the maximum number of entries divided
by the load factor, no
rehash() operations will ever
lps.xml file contains configuration options for
specifying a security 'white-list/black-list' for LPS back-end data/media requests
allowing/denying gzip content-encoding based on user-agent
allowing/denying persistent connections based on user-agent
Here is an example on what this file can look like:
<lps-configuration> <!-- Default options --> <option name="content-encoding-user-agent" > <deny> <!-- Deny Netscape 4.7* --> <pattern>Mozilla/4\.7[0-9]* .*</pattern> </deny> </option> <option name="connection-user-agent" > <deny> <!-- Deny Safari --> <pattern>Safari</pattern> </deny> </option> <application path="/examples/dataimage.lzx" > <option name="proxy-security-urls"> <allow> <pattern>http://.*\.images\.com/.*</pattern> <pattern>http://.*\.adobe\.com/.*</pattern> </allow> </option> </application> <application path="/examples/data.lzx" > <option name="proxy-security-urls" > <deny> <pattern>http://.*\.foobar\.net/.*</pattern> </deny> </option> </application> <!-- Deny requests under /secret in the foobar.com domain --> <!-- for LZX files that begin with /data. --> <application pattern="/data.*\.lzx" > <option name="proxy-security-urls" > <deny> <pattern>http://*\.foobar\.net/.*</pattern> </deny> </option> </application> </lps-configuration>
determines which user-agents are allowed/denied content-encoding.
white-list/black-list of allowed/prohibited request URLs.
<option> can have one of two elements:
<deny> tags contain a
list of regular expression patterns to be matched. For example, to
disallow content encoding for Netscape 4.7:
<option name="content-encoding-user-agent" > <deny> <pattern>Mozilla/4\.7[0-9]* .*</pattern> </deny> </option>
Or to only allow requests to fetch data from the
<option name="proxy-security-urls" > <allow> <pattern>http://.*\.laszlosystems\.com/.*</pattern> <pattern>http://.*\.foobar\.com/.*</pattern> </allow> </option>
Both path and pattern are relative to the web application name.
To match the application path
and only allow URL requests that for any directory under
path="/examples/dataimage.lzx"> <option name="proxy-security-urls"> <allow> <pattern>http://.*\.images\.com/.*</pattern> <pattern>http://.*\.adobe\.com/.*</pattern> </allow> </option> </application>
pattern="/examples/data.*\.lzx"> <option name="proxy-security-urls"> <deny> <pattern>http://.*\.foobar\.com/.*</pattern> </deny> </option> </application>
The OpenLaszlo Server uses the following precedence to determine which filter will be applied to your application:
There is a matching application path attribute and it contains a matching option.
There is a matching application pattern attribute and it contains a matching option.
There is matching global option.
The OpenLaszlo Server provides a highly configurable and efficient logging mechanism that you can use to debug and monitor server activities.
The server uses the well-known Log4j
package for logging details about its operation. You can configure LPS
logging by modifying elements of the
log4j:configuration tag in the lps.xml
configuration file. The default location for the detailed log file
is inside the web application's WEB-INF directory at
You can change the location of this file using a "File" parameter in the
lps appender. For example,
<appender name="lps" class="org.apache.log4j.RollingFileAppender"> <param name="File" value="lps.log"/> <!-- other settings here --> </appender>
will leave the log in the default location inside the web applications's
WEB-INF directory. You can also modify the amount of logging done by
changing the priority of your logger from
debug. For more details on this file see the
There's also the detailed
doc about the pattern layout for controlling the format of each log
statement. The default settings will keep 5 backup log files each with a maximum
size of 10 MBytes. You can change them by using the MaxBackupIndex param and
MaxFileSize param in the lps appender. For example, the following will keep 20
backup log files with a maximum size of 5 MBytes.
<appender name="lps" class="org.apache.log4j.RollingFileAppender"> <param name="MaxBackupIndex" value="20"/> <param name="MaxFileSize" value="5MB"/> <!-- other settings here --> </appender>
Your servlet container will likely maintain logs of its own. See your servlet container documentation of the location and configuration of these logs.
The default configuration that ships with the OpenLaszlo Server also includes a logger named,
org.openlaszlo.exceptions. The server will log unexpected
exceptions to this logger. During development this logger should be left as
WARN or ERROR level, but most deployments will prefer to comment it out, unless
they are troubleshooting.
Logging can be configured during runtime with the
lzt=logconfig request type. The request by itself returns the
server's log4j configuration. You can modify and tell the OpenLaszlo Server to read your new
configuration options by passing a
parameter. The server always looks for a log4j.xml file first in the server's
configuration directory before checking for the <log4j:configuration>
element in lps.xml.
You can also pass a new XML configuration to the server by sending using the
To save your new settings into a log4j.xml file that your server can use as your default log configuration, send
save=1 with your new settings.
There are two values for this property:
Fetch the WSDL from the backend for every load of a SOAP object.
Fetch the WSDL from the backend once during startup. Subsequent loads will fetch WSDL from cache.
never during deployment and
development. Default is
always. You'll need to restart the
server for changes to take effect.
The Apache Axis library is used to support SOAP in the OpenLaszlo Server. The server uses HttpClient as its HTTP transport of choice through its configuration of WEB-INF/lps/config/client-config.wsdd.
<?xml version="1.0" encoding="UTF-8"?> <deployment name="commonsHTTPConfig" xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender" /> </deployment>
The CommonsHTTPSender class uses HttpClient to call SOAP services.
This file contains the set of users recognized by the default security servlet (used by the default OpenLaszlo Server authenticator interface). The authenticator is used by to authenticate users who attempt to connect to the ther sever via the Persistent Connection Manager.
In parallel with the
config directory in
WEB-INF/lps there is
a directory named
config-deploy which contains a sample OpenLaszlo configuration
for deployment purposes. To use this directory, simply delete, move, or rename
config directory out of the way and copy, rename the
config. You should definitely review the configuration and modify it to suit your needs.
Of course you will have to (re)start your OpenLaszlo Server.
As noted above, by default the OpenLaszlo Server is set up as an open proxy. As with any servlet (or CGI), the OpenLaszlo Server is a program that responds to web queries. When connected to the big, bad, internet, it is possible that an unexpected or malformed query can exercise an unexpected code path that could lead to failure of the servlet or to the servlet's being exploited to take control of the server on which it is hosted. Therefore the OpenLaszlo Server should not be deployed as an open server without careful consideration of these issues. If you are using Tomcat as your servlet container, we recommend the security chapter of the O'Reilly Tomcat book which discusses how to secure a Tomcat server. If you are using another servlet container, you should consult that provider's documentation on how to best secure your system.
In addition, you can use OpenLaszlo'swhite-listing and black-listing capabilities to limit access.
The OpenLaszlo Server and OpenLaszlo applications inherit the security of the container in/from which they are deployed. If you would like to serve OpenLaszlo applications over secure HTTPS transport, you will need to enable this feature in your servlet container.
With few exceptions, OpenLaszlo applications work identically when served over HTTPS. The two exceptions are:
There is increase in server and client CPU load to handle the encryption/decryption that is part of HTTPS/SSL.
An HTTPS-served application can make runtime HTTPS data and media requests without any additional configuration.
OpenLaszlo applications served over standard (insecure) HTTP transport can make secure runtime HTTPS requests. These requests are transported securely from the client to the OpenLaszlo Server. (They are also transported securely from any back-end to the server itself).
SWF only: The features described in this section only work in applications compiled to SWF. They do not work in applications compiled to other runtimes.
OpenLaszlo applications served over (insecure) HTTP that run
in the Macromedia Flash 7 player may require additional server configuration to
access runtime data and media over secure HTTPS. According to Macromedia
documentation, you will need to provide a cross-domain policy file that explicitly
allows such access to your remote data. OpenLaszlo provides a sample (and lenient)
cross-domain policy file (
that, when copied to the root
directory of the front-most server that serves the
OpenLaszlo application, will enable HTTPS access from applications that
are loaded over (insecure) HTTP from any server.
If you need to support HTTPS access from HTTP-loaded apps, you should
read this example file and follow the instructions inside it before copying.
Macromedia article on security in Flash 7 for details on the format and
interpretation of the cross-domain policy file.
If you are running the OpenLaszlo Server inside a servlet container and
the servlet container is directly accessible, then the file
crossdomain.xml should be placed in
container's ROOT web application. See your servlet container's documentation for
locating this directory.
If you are fronting your container with another server such as Apache, this file
needs to be placed in that server's root directory. For example, with Apache,
this would be Apache's DocumentRoot directory (or the root of
Apache's virtual host directory for the host that's serving the application).
The configuration of your servlet container (or front-side server) can also affect the security of the LPS. To prevent certain denial-of-service (DOS) attacks, you may want to configure the max size of an HTTP request body, the maximum size of an HTTP request header, the maximum number of HTTP headers in a request, and the maximum size of the initial request line (url and query string).
The OpenLaszlo Source Viewer, which ships with the OpenLaszlo Server, allows anyone with internet access to read any XML files,
including sources to any .lzx program,
in your LPS directory by using a query such as, for example,
To prevent this, remove or rename the
viewer directory from the
lps/lps/utils directory and set
allowRequestSOURCE=false in the Section 6.4, “WEB-INF/lps/config/lps.properties”.
Also note that source code to your applications may be made visible through the context ("right click") menu. See Chapter 31, Input Devices and Gestures for a discussion about how to disable this programmatically.
You can monitor OpenLaszlo Server activity by looking at the log file. You can examine the log file directly on the server (see above for locating the log file).
See also the next section on server statistics.
Different browsers vary in their support for options such as gzip compression and http request options . The table below summarizes known browser capabilities at this time. As explained in section WEB-INF/lps/config/lps.xml, the lps.xml file is configured with regexp patterns which specify these browsers by matching on their user-agent string.
|Doesn't support gzip correctly||Say they support gzip but don't||Don't support if-modified-since correctly||Can't abort an HTTP request|
|Older Safaris, MAC IE5.2||See lps.xml table||Everything but Safari||Mac IE5.2, NS 4.7x|
You can use the lzt=stat request type to track server statistics. You will need to verify that you have the stat request type enabled in your lps.properties. The stat request type will return XML showing general server configuration, server load for the past 1/5/15 minutes, and information on the number of unique data and media urls. Note that administrative requests are not included in these statistics.
The server keeps track of the following loads:
application: load on server for LZX application requests.
media: load on server for media requests, e.g., mp3, gif.
data: load on server for data requests.
persistent connection: number of active persistent connections.
all: sum of application, media, and data loads.
The server also keeps track of the number of unique data and media urls that have been requested. You can toggle url details at run-time by using the durl=[0|1] and murl=[0|1] query string parameters for data and media urls, respectively. By default, url details are turned off. See lps.properties for more info.
SWF files are internally gzip-compressed, which results in smaller files, especially when those files consist primarily of script, as do most OpenLaszlo-compiled applications. As a result, the smallest SWF-compiled OpenLaszlo application, which includes the LFC, is approximately 60K in size. The comparable DHTML-complied OpenLaszlo application, in contrast, is approximately 250K. This would be a serious problem, except that gzip compression is supported as part of the HTTP standard, and can be enabled in various ways, including by settings on the Web server (Apache Web Server or similar) or, when the deployment includes the OpenLaszlo server, in the Java server environment.
The effect of this compression, when correctly enabled in the serving environment, is that the compression is actually slightly better than the internal gzip compression supported by the SWF file format. Our measurements indicate that the 250K compresses down to 50K.
The client-side configuration is much easier; the HTTP protocol specifies "content codings" which may include
gzip. A properly configured server will add the appropriate
content-coding=gzip header, and modern browsers will recognize that that header means that the
content will be gzipped. With todays browsers (including all browsers supported by OL4), this does not require any client-side
Copyright © 2002-2010 Laszlo Systems, Inc. All Rights Reserved. Unauthorized use, duplication or distribution is strictly prohibited. This is the proprietary information of Laszlo Systems, Inc. Use is subject to license terms.