Abstract

Web-based technologies often are the glue that bind together heterogeneous applications. When Web-enabling applications (for user or for machine access), it is necessary to integrate Web technologies into the application. However, rather than implementing various Web technologies as an integral part of an application, it is often advantageous to let specialized Web components (like a Web server) handle the mechanics of Web interactions.

Class Survey

Example: HTML Forms

• HTML forms are normal Web pages (using form elements)
• The process receiving the form data produces a result page
• How does the Web server communicate with the application server?
  • is that channel fast? reliable? secure?
  • can I change my Web server without having to rewrite my application?

HTTP Service

• HTTP provides basic URI-based services
  • handling URI redirections and URI rewriting
  • content negotiation based on HTTP headers and server configuration
  • but finally, some resource representation (i.e., URI-based content) has to be returned
• HTTP relies on some content provider for delivering the representation
  • in simple cases, the file system is the content provider
  • HTTP servers may do a bit of content provision themselves (SSI)
  • there can be arbitrarily complex logic behind the process of providing content

Web Pages

• Files (i.e., resource representations) can have a number of properties
  • the language of their content
  • the media type they are using for their content
  • for text-based media types, the character set and character encoding
• Different representations can be provided in different ways
  • they might be provided as static files, produced manually
  • they might be generated on demand
  • for language variants, manual production is more likely
• File systems are simple (and bad) Content Management Systems (CMS)
  • navigation information can be inferred from the available content
  • access to content can be based on workflows and authentication
  • document production can be automated (your daily news digest)

Server-Side Processing

• A request results in a file that has to be served
  • this may happen after URI redirection, rewriting, or content negotiation
  • the file is read from the file system and included in the HTTP response
  • response headers are set as configured for the server
• The file is copied directly to the HTTP response
  • the fastest way from the disk to the network
  • anything else would affect highly loaded Web server negatively
• Documents may contain code which should be interpreted
  • this could be very simple information like insert the file's modification date
  • as a consequence, the complete file must be parsed before it can be sent

Which Server?

SSI Configuration

• The Web server must allow SSI to be used
  • the SSI module mod_include must be compiled into the server
  • Options Includes must be set to enable SSI processing
• The Web server must know which files it should parse
  • parsing all files would slow down processing unnecessarily
  • Apache supports two different ways of marking a file as SSI
  1. the file extension can be used (files must be named as set)

     AddType text/html .shtml
     AddHandler server-parsed .shtml

  2. the file mode (only available in Unix file systems) can be used (files must be chmod +x)

     XBitHack on

• The fist way is cleaner and more portable (across OS)
  • any decent Web server should not expose file extensions anyway

Basic SSI

• SSI directives are mostly used for simple tasks
• The server replaces the directive with the result
  • the syntax uses HTML comment syntax

    <!--#element attribute=value attribute=value … -->

• Some directives return frequently used values
  • these values depend on the individual request

    <!--#echo var="DATE_LOCAL" -->

    <!--#echo var="LAST_MODIFIED" -->

    <!--#config timefmt="%A %B %d, %Y" -->

• Directives may include other files
  • depending on these files, SSI may be nested

    <!--#include virtual="footer.shtml" -->

Processing Problems

• SSI directives are executed
• Whenever things are executed, problems may occur
  • less likely for including date and time information
  • more likely for including other files
• SSI error handling is very simple
  • standard error text: [an error occurred while processing this directive]

    <!--#config errmsg="[ It appears that you don't know how to use SSI ]" -->

    SSIErrorMsg "[ It appears that you don't know how to use SSI ]"

  • for production systems, it makes more sense to not display error messages

    SSIErrorMsg "<!-- Error -->"

Advanced SSI

• SSI pages can use conditional code
  • the variables are environment variables or set by Apache's SetEnvIf

    <!--#if expr="test_condition" -->
    <!--#elif expr="test_condition" -->
    <!--#else -->
    <!--#endif -->

• Directives may invoke external programs
  • the call mechanism is through the Common Gateway Interface (CGI)

    <!--#include virtual="/cgi-bin/counter.pl" -->

  • this may introduce security issues (everybody can invoke the program)
• Directives may invoke OS commands
  • this works in the same way as the OS shell

    <!--#exec cmd="dir" -->

  • this introduces major security issues (everybody can invoke the command)
  • IncludesNOEXEC enables SSI but disables exec

Web Server Service

• Web Servers negotiate services on the URI level
  • this may include useful activities, but not the eventual application logic
• URIs are often handled by code rather than just being files
  • SSI is useful for simple tasks
  • more complex tasks require applications to handle the request
• How can Web servers and applications interface in a portable way?
  • the Common Gateway Interface (CGI) defines a server/application interface
  • CGI-based applications can easily switch the front-end Web server
• Different perspectives depending on your use case
  • on multi-user Web servers, users want to run their personal programs
  • on large Web servers, the Web server should remain exchangeable

CGI Basics

• Synchronous processing of HTTP requests
  • CGI programs should not take more than a few seconds
  • your CGI program can be invoked by anybody using the Web
• Web server and CGI programs communicate through four channels
  1. the command line (same as Unix command line)
  2. environment variables
  3. standard input
  4. standard output
• Input data is not constrained by anything
  1. Web forms may be easily circumvented
  2. many scripting languages have buffer overflow problems
  3. CGI programs can be installed by anybody
  4. most servers run CGI programs in suEXEC mode

CGI-Based HTML Forms

CGI Problems

• CGI programs are executed for each request
  • process creation is a rather expensive OS functionality
  • for many requests using the same CGI, this is very ineffective
• CGI depends on individual processes for each request
  • setting the process environment is necessary
  • a process's environment cannot be reset
• CGI uses local mechanisms for communications
  • Web server and CGI program must run on the same machine

FastCGI

• CGI introduces performance problems
  • heavily loaded servers with the same CGI program reused frequently
  • the program is started and terminated very often
• FastCGI multiplexes all CGI information over TCP
  • all information is sent over a channel which is reusable
  • the channel can remain open after a request has being sent
  • TCP supports distribution of Web server and CGI programs

Applications Anywhere

• Java was planned to be write once, run anywhere
• The Web was an ideal platform for this
• Applets are a special kind of Java application
  • they implement a special interface (java.applet.Applet)
  • they run in a restricted execution environment (the browser's applet sandbox)
• Applets have become unpopular
  • security considerations
  • performance issues
  • why use a Web browser in the first place? Java Web Start!

Server-Side Java

• Applets introduce client-side problems
  • not available due to software problems
  • disabled because of security issues
• Servlets are Web-oriented Java-code on the server side
  • they need a Java environment on the server side
  • they implement the class javax.servlet.http.HttpServlet for handling requests
  • they contain the complete logic for producing responses

Servlet problems

• Servlets are called for HTTP requests
  • they contain all code necessary for handling the request
  • this often means some mix of HTML and Java code
  • pure servlets turned out to produce poorly maintainable Web sites
• Servlets should better separate logic and layout
  • Java Server Pages (JSP) embed Java in HTML (rather than vice versa)
  • Java Server Faces (JSF) provide a variety of Web-based GUI controls

Web Server Services

• HTTP service often only is the front stage
• HTTP servers need to interface to applications
• CGI is a popular server/service interface