Есть ли способ создать базовый HTTP-сервер (поддерживающий только GET / POST) в Java, используя только API Java SE, без написания кода для ручного разбора HTTP-запросов и ручного форматирования HTTP-ответов? Java SE API прекрасно инкапсулирует функциональность HTTP-клиента в HttpURLConnection, но есть ли аналог для функциональности HTTP-сервера?
Просто чтобы быть ясным, проблема, с которой я сталкиваюсь со многими примерами ServerSocket, которые я видел в Интернете, заключается в том, что они выполняют свои собственные синтаксический анализ / форматирование запросов и обработку ошибок, что утомительно, подвержено ошибкам и вряд ли будет всеобъемлющим, и я пытаюсь избежать этого по этим причинам.
В качестве примера ручной манипуляции HTTP, которую я пытаюсь избежать:
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html
источник
Ответы:
Начиная с Java SE 6 в
SunOracle JRE имеется встроенный HTTP-сервер .com.sun.net.httpserver
Резюме пакета описывают задействованные классы и содержат примеры.Вот начальный пример, скопированный из их документов (тем не менее, для всех, кто пытается его редактировать, потому что это уродливый кусок кода, пожалуйста, не копируйте, а не мой, более того, вы никогда не должны редактировать цитаты, если они не изменились. в первоисточнике). Вы можете просто скопировать и запустить его на Java 6+.
Следует отметить, что
response.length()
роль в их примере плохая, так и должно бытьresponse.getBytes().length
. Даже в этом случаеgetBytes()
метод должен явно указывать кодировку, которую вы затем указываете в заголовке ответа. Увы, хотя и вводящий в заблуждение начинающих, в конце концов, это всего лишь базовый пример.Выполните его и перейдите по адресу http: // localhost: 8000 / test, и вы увидите следующий ответ:
Что касается использования
com.sun.*
классов, обратите внимание, что это, в отличие от того, что думают некоторые разработчики, абсолютно не запрещено общеизвестными часто задаваемыми вопросами. Почему разработчики не должны писать программы, называющие «солнечные» пакеты . Этот FAQ касаетсяsun.*
пакета (такого какsun.misc.BASE64Encoder
) для внутреннего использования Oracle JRE (который, таким образом, убьет ваше приложение при запуске его на другом JRE), а неcom.sun.*
пакета. Sun / Oracle также просто разрабатывает программное обеспечение поверх API Java SE, как и любая другая компания, такая как Apache и так далее. Использованиеcom.sun.*
классов не рекомендуется (но не запрещено), когда это касается реализации определенного API Java, такого как GlassFish (Java EE impl), Mojarra (JSF impl), Джерси (JAX-RS impl) и т. Д.источник
sun.*
сcom.sun.*
. Например, вы видите документацию поsun.*
API? Посмотрите здесь: java.sun.com/products/jdk/faq/faq-sun-packages.html Это говорит о чем-нибудьcom.sun.*
?com.sun.*
Используется только для их собственного общественного программного обеспечения , которое не является частью Java API. Они также разрабатывают программное обеспечение поверх Java API, как и любая другая компания.@jdk.Exported
в исходном коде OpenJDK, что означает, что API считается общедоступным и будет доступен в Java 9 (некоторые другиеcom.sun.*
пакеты станут недоступными из-за Project Jigsaw).Проверьте NanoHttpd
«NanoHTTPD - это легкий HTTP-сервер, разработанный для встраивания в другие приложения, выпущенный по модифицированной лицензии BSD.
Он разрабатывается в Github и использует Apache Maven для сборок и модульного тестирования ».
источник
GET /../../blahblah http/1.1
выдается подобный запрос, и сервер проходит над корнем веб-сайта и попадает в область системных файлов, обслуживая файлы, которые могут быть использованы для взлома или удаленной атаки на систему, например файл паролей.Решение com.sun.net.httpserver не переносится между JRE. Лучше использовать официальный API веб-сервисов в javax.xml.ws для загрузки минимального HTTP-сервера ...
РЕДАКТИРОВАТЬ: это на самом деле работает! Приведенный выше код выглядит как Groovy или что-то в этом роде. Вот перевод на Java, который я тестировал:
источник
text/xml
.Мне нравится этот вопрос, потому что это область, где постоянно происходят инновации, и всегда необходимо иметь легкий сервер, особенно когда речь идет о встроенных серверах в небольших (э) устройствах. Я думаю, что ответы делятся на две большие группы.
В то время как я мог бы считать, что HTTP-библиотеки, такие как: Jetty , Apache Http Components , Netty и другие, больше походят на необработанные средства обработки HTTP. Маркировка очень субъективна и зависит от того, что вам нужно для небольших сайтов. Я делаю это различие в духе вопроса, особенно замечание о ...
Эти необработанные инструменты позволяют вам сделать это (как описано в других ответах). Они на самом деле не поддаются готовому стилю создания легкого, встроенного или мини-сервера. Мини-сервер - это то, что может дать вам функциональность, аналогичную полнофункциональному веб-серверу (например, Tomcat). ) без наворотов, малой громкости, хорошей производительности в 99% случаев. Тонкий сервер кажется ближе к оригинальной фразировке чуть больше, чем простой, возможно, с ограниченной функциональностью подмножества, достаточной для того, чтобы вы выглядели хорошо в 90% случаев. Моя идея «сырого» бытия заставляла меня выглядеть хорошо 75–89% времени без лишнего дизайна и кодирования. Я думаю, что если / когда вы достигнете уровня WAR-файлов, мы оставим «маленький» для бонси-серверов, который выглядит как все, что большой сервер делает меньше.
Варианты тонкого сервера
Параметры мини-сервера:
Среди прочего, я бы хотел включить аутентификацию, валидацию, интернационализацию, использование чего-то вроде FreeMaker или другого инструмента шаблона для визуализации вывода страницы. В противном случае управление редактированием и параметризацией HTML может привести к тому, что работа с HTTP будет выглядеть как крестики-нолики. Естественно, все зависит от того, насколько гибким вам нужно быть. Если это факсимильный аппарат на основе меню, это может быть очень просто. Чем больше взаимодействий, тем « плотнее » должна быть ваша структура. Хороший вопрос, удачи!
источник
Загляните на веб-сервер Jetty Jetty . Превосходная часть программного обеспечения с открытым исходным кодом, которое, казалось бы, отвечает всем вашим требованиям.
Если вы настаиваете на том, чтобы катиться самостоятельно, взгляните на класс «httpMessage».
источник
Когда-то я искал что-то похожее - легкий, но полностью функциональный HTTP-сервер, который я мог бы легко встраивать и настраивать. Я нашел два типа потенциальных решений:
Итак ... Я намеревался написать JLHTTP - облегченный HTTP-сервер Java .
Вы можете встроить его в любой проект в виде единого (если довольно длинного) исходного файла или в виде баночки ~ 50 КБ (без ~ 35 К) без каких-либо зависимостей. Он стремится быть RFC-совместимым и включает в себя обширную документацию и множество полезных функций, сохраняя при этом раздутость до минимума.
Возможности включают в себя: виртуальные хосты, обслуживание файлов с диска, сопоставления типов MIME через стандартный файл mime.types, генерацию индекса каталога, файлы приветствия, поддержку всех методов HTTP, поддержку условных ETag и заголовков If- *, кодирование передачи по частям, gzip / deflate сжатие, базовый HTTPS (как предусмотрено JVM), частичное содержимое (продолжение загрузки), обработка нескольких частей / данных формы для загрузки файлов, множественные обработчики контекста через API или аннотации, разбор параметров (строка запроса или x-www-form-urlencoded тело) и т. д.
Я надеюсь, что другие найдут это полезным :-)
источник
Очень простой веб-сервер, написанный на Java, можно найти здесь http://library.sourcerabbit.com/v/?id=19.
источник
Spark является самым простым, вот краткое руководство: http://sparkjava.com/
источник
Можно создать http-сервер, который обеспечивает базовую поддержку для сервлетов J2EE, используя только JDK и API сервлетов в нескольких строках кода.
Я нашел это очень полезным для модульного тестирования сервлетов, так как он запускается намного быстрее, чем другие легкие контейнеры (мы используем пристань для производства).
Большинство очень легких http-серверов не обеспечивают поддержку сервлетов, но они нам нужны, поэтому я решил поделиться.
Приведенный ниже пример предоставляет базовую поддержку сервлетов или throws и UnsupportedOperationException для вещей, которые еще не реализованы. Он использует com.sun.net.httpserver.HttpServer для базовой поддержки http.
источник
Я настоятельно рекомендую заглянуть в Simple , особенно если вам не нужны возможности Servlet, а просто доступ к объектам request / reponse. Если вам нужен REST, вы можете поставить поверх него Джерси, если вам нужно вывести HTML или аналогичный, есть Freemarker. Я действительно люблю то, что вы можете сделать с этой комбинацией, и есть относительно мало API для изучения.
источник
Этот код лучше нашего, вам нужно всего лишь добавить 2 библиотеки: javax.servelet.jar и org.mortbay.jetty.jar .
Класс Причала:
Класс сервлетов:
источник
*.Servlet.jar
и*.jetty.jar
, очевидно, не являются частью Java SE.Вы также можете взглянуть на некоторые приложения NIO, такие как:
источник
Все вышеперечисленное подробно описывает детали обработки запросов с одним основным потоком.
установка:
Позволяет выполнять несколько запросов через несколько потоков, используя службу executor.
Таким образом, код конца будет примерно таким:
источник
выписка Простой . это довольно простой встраиваемый сервер со встроенной поддержкой для самых разных операций. Особенно мне нравится его многопоточность модели ..
Удивительный!
источник
Проверьте
takes
. Посмотрите на https://github.com/yegor256/takes для быстрой информацииисточник
Как насчет проекта Apache Commons HttpCore ?
С веб-сайта: ... HttpCore Цели
источник
Попробуйте это https://github.com/devashish234073/Java-Socket-Http-Server/blob/master/README.md
Этот API создает HTTP-сервер с использованием сокетов.
Например, вот как конструктор в
Response.java
классе преобразует необработанный ответ в ответ http:источник
Вы можете написать довольно простой встроенный Jetty Java-сервер .
Встроенный Jetty означает, что сервер (Jetty) поставляется вместе с приложением, а не развертывается на внешнем сервере Jetty.
Так что, если подход не встроен, ваше веб-приложение встроено в WAR-файл, который развернут на каком-то внешнем сервере ( Tomcat / Jetty / etc), во встроенном Jetty вы пишете веб-приложение и создаете экземпляр сервера Jetty в той же кодовой базе.
Примером для встроенного Java-сервера Jetty вы можете воспользоваться git clone и использовать: https://github.com/stas-slu/embedded-jetty-java-server-example
источник