Простой HTTP-сервер в Java с использованием только Java SE API. Самый "легкий" Java - сервер
Последнее обновление: 20.09.2018
Класс Java Bean должен соответствовать ряду ограничений:
иметь конструктор, который не принимает никаких параметров
определять для всех свойств, которые используются в jsp, методы геттеры и сеттеры
названия геттеров и сеттеров должны соответствовать условностям: перед именем переменной добавляется get (для геттера) и set (для сеттера), а название переменной включается с большой буквы. Например, если переменная называется firstName, то функции геттера и сеттера должны называться соответственно getFirstName и setFirstName.
Однако для переменных типа boolean для функции геттера используется вместо get приставка is. Например, переменная enabled и геттер isEnabled.
реализовать интерфейс Serializable или Externalizable
Рассмотрим, как использовать классы JavaBean. Допустим, у нас есть следующая структура:
В папке Java Resources/src расположен класс User со следующим кодом:
Import java.io.Serializable; public class User implements Serializable { private static final long serialVersionUID = 2041275512219239990L; private String name; private int age; public User() { this.name = ""; this.age = 0; } public User(String name, int age) { this.name = name; this.age = age; } public String getName() { return name; } public void setName(String name) { this.name = name; } public int getAge() { return age; } public void setAge(int age) { this.age = age; } }
Данный класс представляет пользователя и является классом Java Bean: он реализует интерфейс Serializable, имеет конструктор без параметров, а его методы - геттеры и сеттеры, которые предоставляют доступ к переменным name и age, соответствуют условностям.
В папке WebContent определена страница user.jsp . Определим в ней следующий код:
Name: ${user.name}
Age: ${user.age}
Данная страница jsp получает извне объект user и с помощью синтаксиса EL выводит значения его свойств. Стоит обратить внимание, что здесь идет обращение к переменным name и age, хотя они являются приватными.
В папке Java Resources/src в файле HelloServlet.java определен сервлет HelloServlet:
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 { User tom = new User("Tom", 25); request.setAttribute("user", tom); getServletContext() .getRequestDispatcher("/user.jsp") .forward(request, response); } }
Сервлет создает объект User. Для передачи его на страницу user.jsp устанавливается атрибут "user" через вызов request.setAttribute("user", tom) . Далее происходит перенаправление на страницу user.jsp. И, таким образом, страница получит данные из сервлета.
Лучший способ понять устройство и принцип работы чего-либо – сделать это что-то самому.
Заинтересовавшись однажды сетевыми технологиями и, среди прочего, серверами, я пришёл к мысли, что было бы неплохо написать одн такой сервер самому, используя Java.
Однако большая часть Java-литературы, что попадалась мне на глаза, если и объясняла нечто по теме, то лишь в самых общих чертах, не идя далее обмена текстовыми сообщениями между клиент-серверными приложениями. В интернете подобная информация встречалась не намного чаще, в основном в виде крупиц знаний на обучающийх сайтах или отрывочных сведений от пользователей разнообразных форумов.
Таким образом, собрав эти знания воедино и написав таки удобоваримое серверное прилоение, спобоное обрабатывать браузерные запросы, я решил сделать выжимку из подобных знаний и поэтапно описать процесс создания простейшего web-сервера на Java.
Надеюсь, в этой статье найдутся полезные знания для начинающих Java-программистов и других людей, изучающих связанные технологии.
Итак, поскольку программа предполагает простейшие функции сервера, она будет состоять из одного класса без графического интерфейса. Этот класс (Server) наследует поток и имеет одно поле – сокет:
Class Server extends Thread {
Socket s;
}
В главном методе создаём новый ServerSocket и задаём для него порт (в данном случае использован порт 1025) и в бесконечном цикле ожидаем соединения с клиентом. При наличии соединения мы создаем новый поток, передавая ему соответствующий сокет. В случае неудачи выводим сообщение об ошибке:
Try { ServerSocket server = new ServerSocket(1025); while(true) { new Server(server.accept()); } } catch(Exception e) { System.out.println("Error: " + e); }
Для того, чтобы сделать возможным создание нового потока подобным образом мы, естественно, должны описать для него соответствующий конструктор. В конструкторе мы маркируем поток как демон и здесь же запускаем:
Public Server(Socket socket) {
this.socket = socket;
setDaemon(true);
start();
}
Далее описываем функционал потока в методе run(): в первую очередь, создаем из сокета поток исходящих и входящих данных:
Public void run() {
try {
InputStream input = socket.getInputStream();
OutputStream output = socket.getOutputStream();
Для считывания входящих данных мы будем применять буфер, представляющий из себя байт-массив определёной размерности. Создание подобного буфера не является обязательным, т.к. возможно принимать входящие данные и другими способами, не лимитируя количество принимаемой информации – но для простейшего web-сервера, описанного здесь, вполне достаточно 64 кбайт для получения необходимых данных от клиента.
Помимо байт-массива, мы также создаем int переменную, которая будет хранить в себе количество реально принятых буфером байт. Это необходимо для того, чтобы в последствии особыми образом создать строку клиентского запроса из полученных данных:
Byte buffer = new byte;
int bytes = input.read(buffer);
String request = new String(buf, 0, r);
В строке request будет содержаться http-запрос от клиента. Среди прочей информации, содержащейся в данном запросе, нас в данный момент интересует адрес запрашиваемого файла и его расширение.
Не вдаваясь в подробности структуры http-запроса скажу лишь, что нужная нам информация будет находиться в первой строчке данного запроса приблизительно в таком виде:
GET /index.html HTTP/1.1
В данном примере запрашивается страница на сервере по адресу
/index.html
Страница с таким адресом выдается на большинстве серверов по умолчанию. Наша задача – с помощью собственноручно написанного метода getPath() вычленить этот адрес из запроса. Существует множество вариантов подобного метода и здесь их приводить нет смысла. Ключевой момент здесь состоит в том, что получив путь до нужного файла и записав его в строковую переменную path, мы можем попробовать создать на основе этих данных файл и, в случае успеха, вернуть этот файл, а в случае неудачи – вернуть специфическое сообщение об ошибке:
String path = getPath(request);
File file = new File(path);
Проверяем, является ли данный файл дирекорией. Если такой файл существует и является директорией, то мы возвращаем упомянутый выше файл по умолчанию – index.html:
Boolean exists = !file.exists();
if(!exists)
if(file.isDirectory())
if(path.lastIndexOf(""+File.separator) == path.length()-1) {
path = path + "index.html";
}
else {
path = path + File.separator + "index.html";
file = new File(path);
exists = !file.exists();
}
Если файла по указанному адресу не существует, то мы создаем http-ответ в строке response с указанием того, что файл не найден, добавляя в нужном порядке следующие заголовки:
If(exists){
String response = "HTTP/1.1 404 Not Found\n";
response +="Date: " + new Date() + "\n";
response +="Content-Type: text/plain\n";
response +="Connection: close\n";
response +="Server: Server\n";
response +="Pragma: no-cache\n\n";
response += "File " + path + " Not Found!";
После формирования строки response мы отправляем их клиенту и закрываем соединение:
Output.write(response.getBytes());
socket.close();
return;
}
Если же файл существует, то перед формированием ответа необходимо выяснить его расширение и, следовательно, MIME-тип. Для начала мы выясним индекс точки, стоящей перед расширением файла и сохраним его в int-переменную.
Int ex = path.lastIndexOf(".");
Затем вычленим расширение файла, стоящее после неё. Список возможным MIME-типов можно расширить, но в данном случае буде использовать всего по одной из форм 3-х форматов: html, jpeg и gif. По умолчанию будем использовать MIME-тип для текста:
String mimeType = “text/plain”;
if(ex > 0) {
String format = path.substring(r);
if(format.equalsIgnoreCase(".html"))
mimeType = "text/html";
else if(format.equalsIgnoreCase(".jpeg"))
mimeType = "image/jpeg";
else if(format.equalsIgnoreCase(".gif"))
mimeType = "image/gif";
Формируем ответ клиенту:
String response = "HTTP/1.1 200 OK\n";
response += "Last-Modified: " + new Date(file.lastModified())) + "\n";
response += "Content-Length: " + file.length() + "\n";
response += "Content-Type: " + mimeType + "\n";
response +="Connection: close\n";
В конце заголовков обязательно должно быть две пустые строки, иначе ответ не будет корректны образом обработан клиентом.
Response += "Server: Server\n\n";
output.write(response.getBytes());
Для отправки самого файла можно использовать следующую конструкцию:
FileInputStream fis = new FileInputStream(path);
int write = 1;
while(write > 0) {
write = fis.read(buffer);
if(write > 0) output.write(buffer, 0, write);
}
fis.close();
socket.close();
}
Наконец, завершаем блок try-catch, указанный в начале.
Catch(Exception e) {
e.printStackTrace();
} }
Поскольку, как уже было сказано, данная реализация web-сервера является одной из простейших, она может быть легко доработана путём добавления графического интерфейса пользователя, количества поддерживаемых расширений, ограничителя подключений и т.п. Одним словом – простор для творчества остаётся огромным. Дерзайте.
Вы можете помочь и перевести немного средств на развитие сайта
Когда я начинал работать в Java EE, серверная инфраструктура казалась мне загадочным капризным монстром. И это при том, что в программирование я пришёл из админов. Залил ear в Resin, проверь, поднялся ли? Успешно ли распаковался? Однажды мы с админами потратили полночи чтобы понять, почему после успешного вроде бы деплоя на запросы отвечает по-прежнему старая копия приложения. При таких танцах с бубном переход на GlassFish казался хорошим решением, а отказ от ejb - ещё лучшим. Кто-то из моих коллег радовался могуществу Spring, кто-то искал что-то попроще... Я писал сервлеты под tomcat, а когда делал что-то совсем маленькое - просто встраивал jetty.
Чем проще, тем лучше. Понятно, что есть нетривиальные требования, есть сложные задачи. Но признаемся себе, сколько простых ненагруженных сервисов вы реализовали используя слишком мощные и сложные инструменты? "Я привык к этому фреймфорку и не хочу терять скилл" - слышу я обычно. "Ты уйдёшь и тот, кто будет поддерживать этот монстрокод, проклянёт тебя" - думаю я в ответ.
Может я и не убедил вас писать простые вещи простыми средствами, но посмотрите все-таки как можно сделать серверное java-приложение вообще без сервера. Это, в конце концов, интересно.
Как, вообще без сервера? Писать обработку запросов самому?
Ну, нет, что вы. Я за простые решения, но не за велосипеды. Все уже написано и, более того, уже установлено. Java-сервер уже есть в вашем jdk. Просто используйте его)
Import
com.sun.net.httpserver.HttpServer
;
import
java.io.IOException
;
import
java.net.InetSocketAddress
;
import
java.util.concurrent.Executors
;
public
class
Main {
private
static
final
int
PORT =
9090
;
public
static
void
main(String
args)
throws
IOException
{
int
port =
PORT;
if
(args.length
>
0
)
{
try
{
port =
Integer
.parseInt
(args[
0
]
)
;
}
catch
(Exception
e)
{
e.printStackTrace
()
;
}
}
HttpServer server =
HttpServer.create
(new
InetSocketAddress(port)
, 0
)
;
server.createContext
("/publish"
, new
PublishHandler()
)
;
server.createContext
("/subscribe"
, new
SubscribeHandler()
)
;
server.setExecutor
(Executors.newCachedThreadPool
()
)
;
server.start
()
;
System
.out
.println
("Server is listening on port "
+
port)
;
}
}
com.sun.net.HttpServer - вот все что нам нужно. Наше приложение будет слушать запросы на порту 9090 или том, что будет указан java -jar наш.jar
тут. Наши обработчики мы навешиваем на контексты перед стартом сервера. Все предельно просто. Чтобы в обработчиках сосредоточиться на бизнес-логике, сделаем им абстрактный предок, где порешаем все мелочи вроде вычитывания параметров зарпроса и логирования пары запрос-ответ:
Import
com.sun.net.httpserver.HttpExchange
;
import
com.sun.net.httpserver.HttpHandler
;
import
java.io.IOException
;
import
java.io.OutputStream
;
import
java.text.SimpleDateFormat
;
import
java.util.Date
;
import
java.util.HashMap
;
import
java.util.Map
;
import
java.util.UUID
;
public
abstract
class
HttpHandlerBased implements
HttpHandler {
protected
abstract
String
doGet(HttpExchange exchange, Map<
String
, String>
params)
;
@Override
public
void
handle(HttpExchange exchange)
throws
IOException
{
String
requestMethod =
exchange.getRequestMethod
()
;
if
(requestMethod.equalsIgnoreCase
("GET"
)
)
{
String
uriStr =
exchange.getRequestURI
()
.getQuery
()
;
String
id =
UUID.randomUUID
()
.toString
()
.replace
("-"
, ""
)
;
log(" "
+
uriStr)
;
Map<
String
, String>
pars =
new
HashMap<
String
, String>
()
;
String
pairs;
if
(uriStr !=
null
&&
uriStr.contains
("="
)
)
{
if
(uriStr.contains
("&"
)
)
pairs =
uriStr.split
("&"
)
;
else
pairs =
new
String
{
uriStr}
;
for
(String
pair :
pairs)
{
String
p =
pair.split
("="
)
;
if
(p.length
==
2
)
{
pars.put
(p[
0
]
, p[
1
]
)
;
}
}
}
String
resp =
doGet(exchange, pars)
;
log(" "
+
resp)
;
exchange.sendResponseHeaders
(200
, resp.length
()
)
;
OutputStream
body =
exchange.getResponseBody
()
;
body.write
(resp.getBytes
("UTF-8"
)
)
;
body.close
()
;
}
}
public
static
void
log(String
msg)
{
System
.out
.println
(new
SimpleDateFormat
("HH:mm:ss:SSS dd.MM.yy"
)
.format
(new
Date
()
)
+
" - "
+
msg)
;
}
}
Имея "за плечами" такого предка, нам останется реализовать метод doGet, в каждом конкретном "сервлете". Метод POST я тут не обрабатываю потому что он мне не нужен. Но обработать его не сложнее, можете попробовать сами.
Итак, что же мы получаем?
Для "секретного web-сервера", по сути внутреннего API java, мы имеем очень приятные инструменты для работы с данными запроса, заголовками ответа и т.п. Все это не требует никакой установки, настройки, есть прямо "в коробке" и готово к работе. Чем не инструмент для простого web-сервиса? Конечно, когда мы проверим свою идею и задумаемся о продакшене, можно перенести свою бизнес-логику в "честные" сервлеты и использовать тот же tomcat или resin. Почему бы и нет? Но если проект не пойдёт в продакшн мы скажем себе спасибо за то, что не привлекали админов, не тратили дни на развертывание и настройку окружения, а просто взяли и сделали то что было нужно. И не более того.
Есть ли способ создать очень простой HTTP-сервер (поддерживающий только GET/POST) в Java, используя только API Java SE, без написания кода для ручного анализа HTTP-запросов и отформатирования HTTP-ответов вручную? Java SE API прекрасно инкапсулирует функциональность HTTP-клиента в HttpURLConnection, но существует ли аналоговый для HTTP-сервер функционал?
Просто, чтобы быть ясным, проблема, с которой я сталкиваюсь с множеством примеров ServerSocket, которые я видел в Интернете, заключается в том, что они выполняют собственный алгоритм синтаксического анализа/отклика запросов и обработку ошибок, что является утомительным, подверженным ошибкам и вряд ли быть всеобъемлющим, и я стараюсь избегать этого по этим причинам.
В качестве примера ручной HTTP-манипуляции, которую я пытаюсь избежать:
18 ответов
Начиная с Java SE 6 в Sun Oracle JRE имеется встроенный HTTP-сервер. В сводке пакета com.sun.net.httpserver описаны участвующие классы и приведены примеры.
Вот начальный пример, скопированный из их документов (тем не менее, всем, кто пытается его редактировать, потому что это ужасный кусок кода, пожалуйста, не копируйте, а не мой, более того, вы никогда не должны редактировать цитаты, если они не изменились. в первоисточнике). Вы можете просто скопировать и запустить его на Java 6+.
package com.stackoverflow.q3732109; import java.io.IOException; import java.io.OutputStream; import java.net.InetSocketAddress; import com.sun.net.httpserver.HttpExchange; import com.sun.net.httpserver.HttpHandler; import com.sun.net.httpserver.HttpServer; public class Test { public static void main(String args) throws Exception { HttpServer server = HttpServer.create(new InetSocketAddress(8000), 0); server.createContext("/test", new MyHandler()); server.setExecutor(null); // creates a default executor server.start(); } static class MyHandler implements HttpHandler { @Override public void handle(HttpExchange t) throws IOException { String response = "This is the response"; t.sendResponseHeaders(200, response.length()); OutputStream os = t.getResponseBody(); os.write(response.getBytes()); os.close(); } } }
Следует отметить, что часть response.length() в их примере плохая, это должна была быть response.getBytes().length . Даже в этом getBytes() метод getBytes() должен явно указывать кодировку, которую вы затем указываете в заголовке ответа. Увы, хотя и вводящий в заблуждение начинающих, в конце концов, это всего лишь базовый пример.
Выполните его и перейдите по адресу http://localhost: 8000/test, и вы увидите следующий ответ:
Что касается использования com.sun.* , Обратите внимание, что это, в отличие от того, что думают некоторые разработчики, абсолютно не запрещено общеизвестными часто задаваемыми вопросами. Почему разработчики не должны писать программы, называющие "солнечные" пакеты . Этот sun.misc.BASE64Encoder часто задаваемых вопросов касается пакета sun.* (Такого как sun.misc.BASE64Encoder) для внутреннего использования Oracle JRE (который, таким образом, уничтожит ваше приложение при запуске его на другом JRE), а не пакет com.sun.* . Sun/Oracle также просто разрабатывает программное обеспечение поверх API Java SE, как и любая другая компания, такая как Apache и так далее. Использование com.sun.* рекомендуется (но не запрещено), когда это касается реализации определенного Java API, такого как GlassFish (Java EE impl), Mojarra (JSF impl), Джерси (JAX-RS impl) и т.д.,
Решение com.sun.net.httpserver не переносится через JRE. Лучше использовать официальный API веб-сервисов в javax.xml.ws для загрузки минимального HTTP-сервера...
Import java.io._ import javax.xml.ws._ import javax.xml.ws.http._ import javax.xml.transform._ import javax.xml.transform.stream._ @WebServiceProvider @ServiceMode(value=Service.Mode.PAYLOAD) class P extends Provider { def invoke(source: Source) = new StreamSource(new StringReader("
Hello There!
")); } val address = "http://127.0.0.1:8080/" Endpoint.create(HTTPBinding.HTTP_BINDING, new P()).publish(address) println("Service running at "+address) println("Type +[C] to quit!") Thread.sleep(Long.MaxValue)EDIT: это действительно работает! Вышеприведенный код выглядит как Groovy или что-то в этом роде. Вот перевод на Java, который я тестировал:
Import java.io.*; import javax.xml.ws.*; import javax.xml.ws.http.*; import javax.xml.transform.*; import javax.xml.transform.stream.*; @WebServiceProvider @ServiceMode(value = Service.Mode.PAYLOAD) public class Server implements Provider