4.1 Introduction

 < Day Day Up > 

In the Web-based world, many of the servers run an HTTP Web server. The traditional way to add customized functions to a Web server has been to write CGI programsstand-alone programs called by an HTTP server when it receives requests for specific pages. Rather than returning static HTML text, the HTTP server starts a CGI program and passes on the user's request, together with many details about the server environment. The CGI program handles the request and returns HTML text to the HTTP server, which transfers it to the user . Figure 4.1 shows this process.

Figure 4.1. How a CGI Program Works

graphics/04fig01.gif

Starting the execution of any programnot just a CGI programcan be a lengthy process. Memory needs to be allocated, the program code needs to be read from disk into memory, references to dynamic libraries need to be linked, standard I/O streams need to be created and connected, and the program needs to process the request.

In a very simple HTTP Web server, multithreading may not be implemented, which means that pending HTTP requests cannot be served until the CGI program returns, possibly after many seconds. However, most modern HTTP servers support multithreading, so this is less of an issue. Yet limits remain on the number of process threads that can be created. When there are large numbers of outstanding requests to an HTTP server, individual threads still need to wait for the previously started CGI programs to complete.

CGI programs are also the target of malicious hacking. Many successful attacks on Web servers have been through poorly written CGI programs, which too often fail to test the parameters passed to them, causing , for example, input-buffer overflows when passed data that is longer than the allocated buffers.

Several alternatives to CGI have been implemented, such as Netscape Connection Application Programming Interface (NSAPI) from Netscape and Internet Connection Application Programming Interface (ICAPI) from IBM. These interfaces permit native software routines to be directly called by the Web server, significantly reducing the startup overhead. However, the add-on routines still need to be compiled for each platform. The various programming interfaces are not fully compatible, restricting the choice of Web server to a particular vendor, although ICAPI, for example, has been designed to include the NSAPI calls. Program testing is even more important, to prevent poorly written software from corrupting the Web server itself.

4.1.1 Java Servlets

Java servlets can be used to overcome these CGI programming issues. A servlet is a platform-independent server-side software component written in the Java language. Servlets run inside a servlet, or Web, container. They extend the capabilities of the underlying Web server because they provide services over the Web, using a request/response paradigm, similar to the CGI programs'.

Servlets were introduced to interactively view and modify data and to generate dynamic Web content. From a high-level perspective, the process flow sequence is as follows .

  1. A client sends a request to a Web server.

  2. The Web server forwards the request to a servlet container.

  3. The servlet container sends the request information to the servlet.

  4. The servlet builds a response and passes it to the servlet container. Depending on the client's request, the content of the response is dynamically constructed .

  5. The servlet container sends the response back to the Web server.

  6. The Web server forwards the response to the client.

This flow is shown in Figure 4.2.

Figure 4.2. Process Flow from a High-Level Perspective

graphics/04fig02.gif

4.1.2 JSP Technology

JSP technology, an extension of the Java servlet technology, offers support for dynamic page content through XML-like tags and scriptlets written in the Java language to encapsulate the logic that generates the content for the page. The code of a simple JSP application, Welcome, is shown in Listing 4.1.

Listing 4.1. Welcome.jsp
 <!DOCTYPE HTML    PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML>    <HEAD>       <META http-equiv="Content-Type" content="text/html">       <META name="GENERATOR" content="IBM WebSphere Studio">       <TITLE>Welcome.jsp</TITLE>    </HEAD>    <BODY>       Welcome,       <%=request.getParameter("firstName")%>       <%=request.getParameter("lastName")%>!    </BODY> </HTML> 

The request to the Welcome application must come from a form that posted two parameters: firstName and lastName . Alternatively, the values of the firstName and lastName variables can be passed to the JSP application as part of the URL. This can be done by appending the following to the URL invoking the JSP application:

 ?firstName=John&lastName=Smith 

In this case, the output of the Welcome application is an HTML page displaying the message:

 Welcome, John Smith! 

Listing 4.1 shows that the Java expressions in a JSP application are enclosed by pairs of delimiters: <%= and %> . The HTML and XML portion of a JSP application is called fixed-template data , or fixed-template text . Fixed-template text often helps a programmer decide whether to use a servlet or a JSP application. JSP applications are more appropriate when most of the content sent to the client is fixed-template data and only a small portion of the content is generated dynamically with Java code. Conversely, servlets are more appropriate when only a small portion of the content sent to the client is fixed-template data. In fact, some servlets do not produce any content. Rather, they perform a task on behalf of their clients and then invoke other servlets or JSP applications to provide a response. In most cases, servlets and JSP applications are interchangeable.

JSP technology allows producing dynamic Web pages with server-side scripting. For flexibility, JSP files can include any combination of in-line Java, <SERVLET> tags, National Center for Supercomputing Applications (NCSA) tags, and JavaBeans. The result is a separation of the presentation logic from the business logic. The objective is to separate the HTML-generation code, which defines the Web page appearance, from the Java code, which implements the business logic, including access to databases.

When a servlet container receives the first request for a JSP application, the runtime translates that JSP application into a Java servlet that handles the current request and future requests to the JSP application. Any errors compiling the new servlet result in translation-time errors. Some servlet containers translate JSP applications to servlets at installation time. This elimitates the translation overhead for the first client that requests each JSP application. In any case, any security considerations about servlets also apply to JSP applications.

 < Day Day Up > 


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net