Руководство java servlet для начинающих

Содержание:

Пример
SecurityContext – хранилище объекта Authentication
- Восстановление Authentication из сессии
Основные функции Servlet
Как работает сервлет
- Жизненный цикл сервлета
Детали уязвимости. Чтение произвольных файлов на сервере
WWW
Упаковка веб-приложения
Servlets Tasks
Example Servlet
Пишем контроллер
Передача данных из сервлета в jsp
Тестовый стенд
Необходимость применения динамических веб-страниц
Объявление и настройка Java web Servlet
Хронология Servlet API

Пример

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

public class NewServlet extends HttpServlet {
   
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        
        // Параметр
        String parameter = request.getParameter("parameter");

        // Старт HTTP сессии
        HttpSession session = request.getSession(true);
        session.setAttribute("parameter", parameter);

        response.setContentType("text/html;charset=utf-8");
        PrintWriter out = response.getWriter();
        try {
            out.println("<html>");
            out.println("<head>");
            out.println("<title>Заголовок</title>");
            out.println("</head>");
            out.println("<body>");
            out.println("<h1>Пример сервлета"+parameter+"</h1>");
            out.println("</body>");
            out.println("</html>");
        } finally {
            out.close();
        }
    } 

    @Override
    public String getServletInfo() {
        return "Пример сервлета)";
    }

}

SecurityContext – хранилище объекта Authentication

Допустим, аутентификация прошла успешно, что значит имя и пароль верные.

В этом случае объект Authentication сохраняется в SecurityContext, а тот в свою очередь в SecurityContextHolder:

SecurityContextHolder

Текущего пользователя из него можно получить так:

SecurityContext context = SecurityContextHolder.getContext();
Authentication authentication = context.getAuthentication();
UserDetails principal = (UserDetails) authentication.getPrincipal();

Таким образом, SecurityContext используется для хранения объекта Authentication.

Восстановление Authentication из сессии

Аутентификация в нашем примере происходит только раз. Коль скоро она прошла успешно, authentication восстанавливается из контекста, а в итоге из сессии при последующих запросах. Происходит это в SecurityContextPersistenceFilter.

Сессии в нашем примере включены – они включены по умолчанию, если их специально не отключить. То есть после аутентификации в HTTP-ответе клиенту отправляется уникальный JSESSIONID, который он отправляет во всех последующих запросах. По JSESSIONID восстанавливается сессия, из нее берется SecurityContext, а из него Authentication.

Основные функции Servlet

Параллельные запросы на сервер обрабатываются потоками, что обеспечивает важные качества веб — многопоточность и параллелизм.

Основные функции:

Портативность. Поскольку Java независима от платформы, то же самое верно и для сервлетов. Например, можно создать его в операционной системе Windows, чтобы разработчики GlassFish использовали его в качестве веб-сервера, а затем могли запустить его в любой другой ОС, такой как Unix, Linux с веб-сервером apache Java Servlet. Эта функция делает его переносимым, и это главное его преимущество над CGI.
Эффективность и масштабируемость. Как только Servlet развертывается и загружается на веб-сервер, он может мгновенно начать выполнение запросов клиентов. Он вызывается легким потоком, поэтому несколько клиентских запросов могут заполняться одновременно, используя функцию многопоточности Java. В отличие от CGI, где сервер инициирует новый процесс для каждого запроса клиента.
Надежность. Наследуя верхние функции Java такие, как сбор мусора, обработка исключений, диспетчер безопасности Java и другие, он менее подвержен проблемам с управлением и утечкам памяти. Это делает разработку приложения в нем безопасной и безошибочной.

Как работает сервлет

Последнее обновление: 17.09.2018

Сервлет — это класс, который расширяет функциональность класса HttpServlet и запускается внутри контейнера сервлетов.

Сервлет размещается на сервере, однако чтобы сервер мог использовать сервлет для обработки запросов, сервер должен поддерживать движок или
контейнер сервлетов (servlet container/engine). Например, Apache Tomcat по сути является контейнером сервлетов, поэтому он может использовать сервлеты
для обслуживания запросов.

Для обработки запроса в HttpServlet определен ряд методов, которые мы можем переопределить в классе сервлета:

doGet: обрабатывает запросы GET (получение данных)
doPost: обрабатывает запросы POST (отправка данных)
doPut: обрабатывает запросы PUT (отправка данных для изменения)
doDelete: обрабатывает запросы DELETE (удаление данных)
doHead: обрабатывает запросы HEAD

Каждый метод обрабатывает определенный тип запросов HTTP, и мы можем определить все эти методы, но, зачастую, работа идет в основном с методами
doGet и doPost. Например, определение методов без реализации:

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
		throws ServletException, IOException {
	}

	protected void doPost(HttpServletRequest request, HttpServletResponse response) 
		throws ServletException, IOException {
	}
	protected void doPut(HttpServletRequest request, HttpServletResponse response) 
		throws ServletException, IOException {
	}

	protected void doDelete(HttpServletRequest request, HttpServletResponse response) 
		throws ServletException, IOException {
		
	}

	protected void doHead(HttpServletRequest request, HttpServletResponse response) 
		throws ServletException, IOException {
		
	}
}

Все методы в качестве параметра принимают два объекта: HttpServletRequest — хранит информацию о запросе и
HttpServletResponse — управляет ответом на запрос.

Жизненный цикл сервлета

Для каждого сервлета движок сервлетов создает только одну копию. Вне зависимости от того, сколько запросов будет отправлено
сервлету, все запросы будут обрабатываться толькой одной копией сервлета. Объект сервлета создается либо при запуске движка сервлетов, либо когда
сервлет получает первый запрос. Затем для каждого запроса запускается поток, который обращается к объекту сервлета.

При работе с сервлетом движок сервлетов вызывает у класса сервлета ряд методов, которые определены в родительском абстрактном классе HttpServlet.

Когда движок сервлетов создает объект сервлета, у сервлета вызывается метод init().
```
public void init(ServletConfig config) throws ServletException { }
```
Этот метод вызывается только один раз — при создании сервлета. Мы можем переопределить этот метод, чтобы определить в нем некоторую логику инициализации.
Когда к сервлету приходит запрос, движок сервлетов вызывает метод service() сервлета. А этот метод, исходя из типа запроса
(GET, POST, PUT и т.д.) решает, какому методу сервлета (doGet, doPost и т.д.) обрабатывать этот запрос.
```
public void service(HttpServletRequest request, HttpServletResponse response) 
		throws IOException, ServletException
{ }
```
Этот метод также можно переопределить, однако в этом нет смысла. В реальности для обработки запроса переопределяются методы onGet, onPost и т.д.,
которые обрабатывают конкретные типы запросов.
Если объект сервлета долгое время не используется (к нему нет никаких запросов), или если происходит завершение работы движка сервлетов,
то движок сервлетов выгружает из памяти все созданные экземпляры сервлетов. Однако до выгрузки сервлета из памяти у сервлета вызывается
метод destroy().
```
public void destroy()
```
При необходимости мы также можем его переопределить, например, определить в нем логику логгирования или что иное. В то же время следует
учитывать, что если сервер вдруг упадет по какой-то причине, например, отключится электричество и т.д., тогда данный метод естественно не будет вызван и его логика не сработает.

Поскольку для обработки всех запросов создается один экземпляр сервлета, и все обращения к нему идут в отдельных потоках, то
не рекомендуется в классе сервлета объявлять и использовать глобальные переменные, так как они не будут потокобезопасными.

НазадВперед

Детали уязвимости. Чтение произвольных файлов на сервере

Apache JServ Protocol (AJP) — это бинарный протокол, созданный ради избавления от избыточности HTTP. AJP гораздо более эффективен, обладает высокой производительностью благодаря значительной оптимизации и отлично масштабируется.

AJP обычно используется для балансировки нагрузки, когда один или несколько внешних веб-серверов (front-end) отправляют запросы на сервер (или серверы) приложений. Сессии направляются к нужному благодаря механизмам роута, где каждый сервер приложений получает свое имя.

В современных Tomcat используется AJP 1.3 (AJP13). Поскольку это двоичный протокол, браузер напрямую не может отправлять запросы AJP13. Поэтому в качестве фронтенда выступает любой популярный веб-сервер — nginx, Apache, IIS.

Вариант взаимодействия с сервером Tomcat через связку веб-сервер — AJP

WWW

Подробнее о протоколе ты можешь прочитать в официальной документации.

По дефолту Tomcat принимает запросы AJP на порте 8009.

/tomcat9.0.30/conf/server.xml

Видим, что директива отсутствует, поэтому AJP доступен на всех IPv4-адресах локальной машины.

По дефолту Tomcat слушает AJP-порт на всех адресах IPv4

Такая настройка крайне небезопасна, и сейчас ты поймешь почему.

Для начала нам нужно разобраться в формате пакетов AJP. Запустим Wireshark и сгенерируем любой легитимный запрос к серверу по AJP. В этом как раз поможет фронтенд в виде веб-сервера Apache.

Снифаем трафик от Apache к Tomcat по протоколу AJP13 через Wireshark

Первые два байта в пакете — это , который меняется в зависимости от направления отправки. Пакеты, отправленные от веб-сервера к контейнеру Tomcat, начинаются с , а от контейнера к веб-серверу — 0x4142 (строка , если переводить в ASCII). В рамках уязвимости нас интересует только структура пакета, отправленного от клиента к контейнеру, то есть .

Следующие два байта — это размер тела пакета. Это обычное числовое значение типа integer. Далее идет байт, который в большинстве случаев указывает на тип сообщения. С него начинается подсчет длины тела пакета.

Существуют следующие типы сообщений от веб-сервера к Tomcat.

Типы пакетов к контейнеру Tomcat

Сразу привлекает внимание пакет с кодом (Shutdown), который выключает сервер. Спешу тебя разочаровать — пакет такого плана обработается только в том случае, если он отправлен с хоста, на котором запущен Tomcat

Нас интересует код . С таким кодом отправляются, например, обычные сообщения типа GET/POST. Формат тела такого сообщения выглядит следующим образом.

За кодом идет метод. Список соотношения базовых методов с их байт-кодами выглядит таким образом.

/tomcat9.0.30/java/org/apache/coyote/ajp/Constants.java

В нашем пакете используется метод GET, поэтому и значение байта — .

В пакете AJP используется метод GET

Далее все содержимое пакета довольно привычно и похоже на обычный HTTP-запрос. После параметра начинается блок заголовков запроса (). Следующие два байта () отвечают за общее количество заголовков в запросе. Следом за ним перечисляются сами хидеры. Каждый заголовок имеет следующий формат:

Коды для стандартных заголовков определены в коде.

Коды стандартных HTTP-заголовков в протоколе AJP

/tomcat9.0.30/java/org/apache/coyote/ajp/Constants.java

Некоторые заголовки крайне важны, например если (0xA008) ненулевой, то Tomcat будет предполагать, что запрос имеет тело (как, например, POST-запрос), и попытается прочитать отдельный пакет.

За блоком хидеров следует блок атрибутов. Его использование опционально, но это самая важная часть для понимания уязвимости.

Существует несколько типов основных атрибутов, каждый из них имеет код, а структура идентична структуре хидеров.

/tomcat9.0.30/java/org/apache/coyote/ajp/Constants.java

Однако любое количество других атрибутов может быть передано и через тип (0x0A). Пара атрибута передается сразу же после указания этого кода. В этом случае структура примет следующий вид:

Например, так передаются переменные окружения. После перечисления необходимых атрибутов отправляется байт-терминатор (0xFF), который означает не только конец списка атрибутов, но и окончание всего пакета. Именно до него считается длина тела пакета.

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Упаковка веб-приложения

Стандартный способ развертывания приложения Java EE заключается в его упаковке с расширением WAR. В командной строчке вводят команду, обязательно в конце указывается точка:

jarcfvdeployQuickServletApp.war -C WebContent.

Программа jar поместит все в каталог в один архив zip-формата под названием Quick.ServletApp.war под каталогом. Теперь разворачивают файл Quick.ServletApp.war на сервере, копируют его в каталог Tomcat. Запускают программу, выполнив Tomcat 7.exe в каталоге. После входа в консоль видно, что файл Quick.ServletApp.war развернут и сервер прослушивает номер порта 8080.

Servlets Tasks

Servlets perform the following major tasks −

Read the explicit data sent by the clients (browsers). This includes an HTML form on a Web page or it could also come from an applet or a custom HTTP client program.
Read the implicit HTTP request data sent by the clients (browsers). This includes cookies, media types and compression schemes the browser understands, and so forth.
Process the data and generate the results. This process may require talking to a database, executing an RMI or CORBA call, invoking a Web service, or computing the response directly.
Send the explicit data (i.e., the document) to the clients (browsers). This document can be sent in a variety of formats, including text (HTML or XML), binary (GIF images), Excel, etc.
Send the implicit HTTP response to the clients (browsers). This includes telling the browsers or other clients what type of document is being returned (e.g., HTML), setting cookies and caching parameters, and other such tasks.

Example Servlet

Let’s now setup a full example of handling information using a form.

To start, let’s define a servlet with a mapping /calculateServlet which will capture the information POSTed by the form and return the result using a RequestDispatcher:

As shown above, classes annotated with @WebServlet must extend the javax.servlet.http.HttpServlet class. It is important to note that @WebServlet annotation is only available from Java EE 6 onward.

The @WebServlet annotation is processed by the container at deployment time, and the corresponding servlet made available at the specified URL patterns. It is worth noticing that by using the annotation to define URL patterns, we can avoid using XML deployment descriptor named web.xml for our Servlet mapping.

If we wish to map the Servlet without annotation, we can use the traditional web.xml instead:

Next, let’s create a basic HTML form:

Finally – to make sure everything’s working as expected, let’s also write a quick test:

Пишем контроллер

Написать сервлет, способный получить данные из формы регистрации, проще простого. Всё, что нам нужно сделать, — это написать подкласс для класса и реализовать его методы или (или оба, если надо). В данном случае сервлет будет взаимодействовать с данными, поступающими из POST-запросов.

Вот как он выглядит:

Первое, на что здесь стоит обратить внимание, — использование аннотации. Она говорит контейнеру сервлета использовать класс для обработки HTTP-запросов по адресу

Того же эффекта можно достичь путём добавления директив сопоставления сервлетов в , как здесь, но так как мы используем Servlet Specification 3.1 нам нет необходимости прибегать к такому способу.

Здесь мы назвали сервлет , так как считается хорошей практикой использовать имя класса сервлета в качестве значения атрибута аннотации . В противном случае некоторые контейнеры не смогут выполнить сопоставление, что приведёт к ошибке 404.

Результат валидации влияет на дальнейший ход событий: если данные не валидны, клиент перенаправляется через объект RequestDispatcher на страницу регистрации, где отображаются соответствующие ошибки. Если всё в порядке, то отображается страница приветствия.

Итак, мы создали целое веб-приложение на Java, которое позволяет зарегистрировать клиентов с помощью HTML-формы, базового сервлета и нескольких JSP-файлов. Пора его запустить.

Передача данных из сервлета в jsp

Последнее обновление: 23.09.2018

Нередко страница jsp обрабатывает запрос вместе сервлетом. В этом случае сервлет определяет логику, а jsp — визуальную часть.
И при обработке запроса сервлет может перенаправить дальнейшую обработку странице jsp. Соответственно может возникнуть вопрос,
как передать данные из сервлета в jsp?

Есть несколько способов передачи данных из сервлета в jsp, которые заключаются в использовании определенного контекста или scope.
Есть несколько контекстов для передачи данных:

request (контекст запроса): данные сохраняются в HttpServletRequest
session (контекст сессии): данные сохраняются в HttpSession
application (контекст приложения): данные сохраняются в ServletContext

Данные из контекста запроса доступны только в пределах текущего запроса. Данные из контекста сессии доступны только в пределах текущего
сеанса. А данные из контекста приложения доступны постоянно, пока работает приложение.

Но вне зависимости от выбранного способа передача данных осуществляется с помощью метода setAttribute(name, value),
где name — строковое название данных, а value — сами данные, которые могут представлять различные данные.

Наиболее распространенный способ передачи данных из сервлета в jsp представляют атрибуты запроса. То есть у объекта HttpServletRequest, который передается в
сервлет, вызывается метод setAttribute(). Этот метод устанавливает атрибут, который можно получить в jsp.

Например, добавим в проект страницу basic.jsp со следующим кодом:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>JSP Application</title>
</head>
<body>
<p>Name: ${name}</p>
<p>Age: ${age}</p>
</body>
</html>

В basic.jsp можно получить атрибуты name и age и вывести их значение на страницу. Для вывода атрибутов применяется специальный
синтаксис EL: в фигурные скобки {} заключается выводимое значение

Контекст запроса

Определим сервлет HelloServlet, который передает запрос basic.jsp и передает ей данные:

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
    		throws ServletException, IOException {
    	
    	request.setAttribute("name", "Tom");
    	request.setAttribute("age", 34);
    	
    	getServletContext().getRequestDispatcher("/basic.jsp").forward(request, response);
    }
}

Сервлет устанавливает два атрибута — «name» и «age» через объект HttpServletRequest и затем перенаправляет запрос странице basic.jsp.

Если мы обратимся к сервлету HelloServlet, то он передаст запрос и данные странице basic.jsp.

Контекст приложения

Использование контекста приложения представляет применение объекта ServletContext, который можно получить в сервлете с
помощью метода getServletContext():

import java.io.IOException;

import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
 
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
    		throws ServletException, IOException {
    	
    	ServletContext selvletContext = getServletContext();
    	selvletContext.setAttribute("name", "Tom");
    	selvletContext.setAttribute("age", 35);
    	
    	getServletContext().getRequestDispatcher("/basic.jsp").forward(request, response);
    }
}

Код страницы basic.jsp при этом не меняется.

Контекст сессии

Подобным образом можно передать данные в jsp через сессию:

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
 
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
 
    protected void doGet(HttpServletRequest request, HttpServletResponse response) 
    		throws ServletException, IOException {
    	
    	HttpSession session = request.getSession();
    	session.setAttribute("name", "Tom");
    	session.setAttribute("age", 34);
    	
    	getServletContext().getRequestDispatcher("/basic.jsp").forward(request, response);
    }
}

НазадВперед

Тестовый стенд

Начнем со стенда для тестирования уязвимости. Для этого достаточно запустить контейнер Docker из официального репозитория Tomcat.

Очень важно расшарить порт 8009, это AJP-протокол, в котором и была найдена уязвимость. Если хочется вместе со мной возиться с отладкой приложения, то нужно действовать немного по-другому

Для дебага я буду использовать IntelliJ IDEA. Сначала скачаем уязвимую версию Apache Tomcat. Я взял 9.0.30. Распакуем и откроем проект в IDEA. Теперь создадим новую конфигурацию отладки с шаблоном Remote

Если хочется вместе со мной возиться с отладкой приложения, то нужно действовать немного по-другому. Для дебага я буду использовать IntelliJ IDEA. Сначала скачаем уязвимую версию Apache Tomcat. Я взял 9.0.30. Распакуем и откроем проект в IDEA. Теперь создадим новую конфигурацию отладки с шаблоном Remote.

Создание шаблона Remote в IDEA

Здесь в поле строка с параметрами, которые нужно указать при запуске сервера. Рекомендую выбрать версию JDK 1.4.x.

Конфигурация отладки. Аргументы для запуска Tomcat в режиме удаленной отладки

Сами параметры можно передать в Docker с помощью ключа или . Переменная окружения, используемая для этих целей, называется

Обрати внимание на опцию : если она включена (), Java будет приостанавливать загрузку виртуальной машины и ждать подключения отладчика и только после успешного коннекта продолжит запуск. У меня получилась такая строка

Запускаем контейнер. Не забывай пробрасывать порт, который указал для удаленной отладки.

Запущенный сервер Tomcat 9.0.30

Открываем браузер, переходим на запущенный сервер (не забывай, что порт — 8080) и наблюдаем страницу 404. Дело в том, что в последних версиях официального докер-контейнера Tomcat папка со стандартными приложениями была переименована в . Достаточно удалить папку и создать симлинк на оригинальную версию директории.

После этого обновляем страницу и видим приветствие сервера Tomcat.

Приветственная страница стенда Tomcat

Tomcat работает, теперь дело за фронтендом, который поможет нам в исследовании AJP. Я создам еще один контейнер на основе Debian.

Понятно из названия, какой веб-сервер я буду использовать в качестве фронта, — Apache. Устанавливаем.

Я выбрал его, так как он проще в настройке прокси до Tomcat. Ты можешь использовать любой другой веб-сервер по желанию.

Включаем модуль для работы прокси с протоколом AJP.

Теперь редактируем стандартный конфиг виртуального хоста () и указываем адрес Tomcat.

И перезагружаем Apache.

Проксируем трафик через Apache к Tomcat по протоколу AJP

Помимо веб-сервера, нам также понадобится какой-нибудь сниффер. Я буду использовать Wireshark. На этом стенд готов. Кстати, если ты не любишь Docker, то есть вариант скачать с сайта разработчика версию с готовыми бинарниками. Все версии можно найти в разделе с архивами.

Теперь можно переходить к разбору уязвимости.

Необходимость применения динамических веб-страниц

Существует немало причин, по которым бизнес хотел бы создавать динамические веб-страницы «на лету», например, когда данные на веб-сайте часто меняются. Сайты новостей и погоды обычно полагаются на CGI, чтобы поддерживать свежий контент, не требующего постоянного внимания разработчиков. Веб-страницы электронной коммерции, в которых перечислены текущие цены и уровни запасов, используют CGI для получения этого контента по требованию, получая его из внутренней инфраструктуры компании.

Многие пользователи имеют опыт использования технологии Джава для создания веб-сервисов на базе CGI, но Java Servlets более эффективны, мощнее, проще в использовании и дешевле традиционных альтернатив CGI.

Преимущества Java Servlets:

Эффективность. В традиционном CGI каждый HTTP-запрос запускает новый процесс CGI. Даже если его код отлично реализован, часто возникает значительный объем накладных расходов не только при запуске процесса, но и во время его выполнения. Когда используются сервлеты, JVM остается загруженным в памяти, и каждый запрос обрабатывается потоком Java. В качестве примера Java Servlet, если в традиционной модели CGI имеется количество X одновременных запросов, это означает, что код для программы загружается в память X раз. Это становится чрезмерной нагрузкой на веб-сервер. Однако в среде сервлета есть потоки X, где запускается только одна копия его класса. Результатом этого является повышение эффективности и масштабируемости на нескольких платформах.
Удобство. При пользовании программой, нет смысла изучать новый язык, например, Perl, только для выполнения функций CGI. Кроме того, сервлеты имеют обширную инфраструктуру для многих задач, связанных с HTML, что значительно ускоряет процесс разработки.
Мощность — к сожалению, традиционные скрипты CGI оставляют желать лучшего. Например, обычные их программы не могут напрямую разговаривать с веб-серверами, что означает, что необходимо создать весь интерфейс. Сервлеты могут напрямую взаимодействовать с веб-серверами, упрощая операции, требующие прямого доступа к хранилищам данных. Они также уникальны, потому что могут обмениваться данными с другими сервлетами и поддерживать информацию между запросами, что делает сеансовое отслеживание чрезвычайно простым.
Переносимость Джава распространяется непосредственно на сервлеты. Фактически почти каждый главный веб-сервер, который в настоящее время используется, поддерживает Java Servlets напрямую или через подключаемый модуль.
Экономность. С точки зрения разработки, внедрение сервлетов намного дешевле, чем другие варианты, которые требуют, чтобы пользовательское кодирование правильно взаимодействовало с веб-серверами. Java Servlet redirect готов к работе и может максимально снизить стоимость бизнеса, не жертвуя преимуществами динамического контента.

Объявление и настройка Java web Servlet

Чтобы сервлет мог обслуживать запросы пользователей, необходимо объявить и настроить сопоставление его в файле дескриптора веб. Создают XML-файл с расширением web.xml ниже каталога WebContent WEB-INF со следующим кодом XML.

Очевидно, что сервлет объявляется с помощью элемента и его дочерних элементов, указывающих описательное имя для него и задающих полное имя класса. Он настроен на обслуживание запросов с использованием элемента и его дочерних частей, указывающих имя, объявленного с помощью элемента и шаблон URL, который должен быть сопоставлен с сервлетом. Шаблон может быть точным совпадением каталога.

Хронология Servlet API

Хронология Servlet API
Servlet API версия	Релиз	Платформа	Важнейшие изменения
Servlet 4.0	JavaEE 8	HTTP/2, Server Push
Servlet 3.1	JavaEE 7, JavaSE 7	Неблокирующий ввод-вывод, поддержка нестандартных протоколов поверх HTTP
Servlet 3.0	JavaEE 6, JavaSE 6	Pluggability, простота разработки, асинхронные сервлеты, безопасность, загрузка файлов
Servlet 2.5	JavaEE 5 , J2SE 5.0	Требует J2SE 5.0, поддержка аннотаций
Servlet 2.4	J2EE 1.4, J2SE 1.3	web.xml использует XML Schema
Servlet 2.3	J2EE 1.3, J2SE 1.2	Появление
Servlet 2.2	J2EE 1.2, J2SE 1.2	Становится частью J2EE, предлагает независимые веб-приложения в .war файлах
Servlet 2.1	не оговорено	Первая официальная спецификация, добавлены ,
Servlet 2.0		JDK 1.1	Часть Java Servlet Development Kit 2.0
Servlet 1.0	Июнь 1997