Static Content vs Dynamic Content

Content delivered by a web server to clients falls into two broad categories: Static and Dynamic. Understanding this distinction clarifies why we maintain separate web servers and WAS, and what role each component plays at each stage.

---

What Is Static Content?

Static content refers to pre-stored files on the server disk that are delivered without any modification to the client. Regardless of who requests it or when, the response is always identical.

Types of Static Content

File Type	Examples	Content-Type
HTML	index.html, about.html	text/html
CSS	style.css, bootstrap.min.css	text/css
JavaScript	app.js, react.min.js	application/javascript
Images	logo.png, banner.webp	image/png, image/webp
Fonts	NanumGothic.woff2	font/woff2
Documents	manual.pdf	application/pdf
Video	intro.mp4	video/mp4

Static Content Processing Flow

Browser: GET /images/logo.png
     │
  [Nginx]
     │  1. Check if /images/logo.png exists
     │  2. Read file from disk
     │  3. Add HTTP response headers (Content-Type, Cache-Control)
     │
  [Response]: 200 OK + PNG binary data
     │
  Image rendered in browser

Nginx configuration example:

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # Serve static files directly
    location /static/ {
        expires 30d;                        # 30-day browser cache
        add_header Cache-Control "public";
    }
}

---

What Is Dynamic Content?

Dynamic content is a response generated by executing a program on the server at the time of the request. The response content varies based on the request time, the requester, and query parameters.

Dynamic Content Examples

Request: GET /api/user/profile
 → Query logged-in user's info from DB
 → Generate JSON: {"name": "John Doe", "email": "john@example.com"}

Request: GET /api/products?category=laptop
 → Query laptop category products from DB
 → Return current stock, pricing, and promotions

Request: POST /api/order
 → Process payment → Save order to DB → Send email
 → Generate order number and respond

Dynamic Content Processing Flow

Browser: GET /api/products
     │
  [Nginx] ──────── Dynamic request detected ────────→ [Tomcat]
                                                           │
                                                     Servlet execution
                                                           │
                                                     DB query (JDBC)
                                                     SELECT * FROM products
                                                           │
                                                     Java object → JSON serialization
                                                           │
  [Browser] ←───── HTTP Response ←────── [Nginx] ←────────┘

---

From CGI to WAS — The Evolution of Dynamic Processing Technology

The WAS we use today emerged through several stages of evolution in dynamic web processing technology.

Stage 1: CGI (Common Gateway Interface, 1993)

The early approach for creating dynamic web content was CGI. When a web server received an HTTP request, it would execute an external program (Perl, C, shell scripts, etc.), and the program would output HTML to stdout, which the web server would deliver to the client.

Browser: GET /cgi-bin/hello.pl
     │
  [Apache] → fork() → [Perl process] → stdout: "Content-Type: text/html\n\nHello!"
     │
  Apache reads stdout and returns response

Problems with CGI: A new process (fork) is created for each request. With 100 concurrent requests, 100 processes are created. This wastes significant memory and CPU resources, and response times are slow.

Stage 2: FastCGI / mod_perl (1996~)

FastCGI emerged to reduce CGI's process creation overhead. By keeping processes running and forwarding requests via socket, it eliminates the need to create a new process for each request. PHP still uses this approach (php-fpm) today.

[Apache/Nginx] ─── FastCGI socket ───→ [php-fpm process pool]
                                           (pre-created PHP workers)

Stage 3: Java Servlet (1997) — The Birth of WAS

In the Java ecosystem, the Servlet specification emerged. A Servlet is a server-side program written as a Java class. Rather than creating a new process like CGI, it handles requests using threads within the JVM.

// Simple Servlet example
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
            throws IOException {
        res.setContentType("text/html; charset=UTF-8");
        PrintWriter out = res.getWriter();
        out.println("<html><body>");
        out.println("<h1>Hello, " + req.getParameter("name") + "!</h1>");
        out.println("</body></html>");
    }
}

Advantages of Servlets:

• Thread-based rather than process-based → significantly improved resource efficiency
• Runs on JVM → platform independence
• Enables object-oriented design

A Servlet container manages the lifecycle of Servlets (creation → initialization → service → destruction). Apache Tomcat is the most representative Servlet container.

Stage 4: JSP (JavaServer Pages, 1999)

With Servlets, generating HTML required writing HTML as strings inside Java code, which was inconvenient. JSP allowed inserting Java code inside HTML files, making it easier for frontend developers to write HTML.

<%@ page language="java" contentType="text/html; charset=UTF-8" %>
<!DOCTYPE html>
<html>
<body>
  <h1>Product List</h1>
  <ul>
  <%
    List<Product> products = productService.findAll();
    for (Product p : products) {
  %>
    <li><%= p.getName() %> - $<%= p.getPrice() %></li>
  <%
    }
  %>
  </ul>
</body>
</html>

Tomcat automatically converts and compiles JSP files into Servlet classes before execution.

Stage 5: MVC Frameworks (2003~)

To solve the problem of mixing business logic and views (HTML) in a single JSP file, MVC pattern and frameworks like Spring MVC and Struts emerged. Most modern Java web applications are built with Spring Boot and its embedded Tomcat.

Stage 6: REST API + SPA (2010s~)

Modern web architecture has shifted to SPA (Single Page Application) where servers provide JSON APIs instead of rendering HTML, and the frontend (React, Vue, etc.) draws the UI with JavaScript.

[React/Vue SPA] ←── GET /static/app.js ──→ [Nginx]  (static file)
[React/Vue SPA] ←── POST /api/login ─────→ [Nginx] → [Tomcat]  (dynamic API)

---

Summary: Static vs Dynamic Processing Comparison

Aspect	Static Content	Dynamic Content
Processor	Web Server (Nginx/Apache)	WAS (Tomcat)
Processing Method	Deliver file from disk as-is	Execute program and generate result
Response Time	Very fast (milliseconds)	Relatively slower (DB queries, etc.)
Caching	Aggressive caching possible	Requires caution (data may change)
Server Load	Very low	High (computation, DB I/O)
Examples	HTML, CSS, JS, images	Login, orders, search, user dashboard

When the web server handles static files upfront, the WAS workload decreases significantly, improving the overall system throughput.