Existe-t-il un moyen de créer un serveur HTTP très basique (prenant uniquement en charge GET / POST) en Java en utilisant uniquement l'API Java SE, sans écrire de code pour analyser manuellement les demandes HTTP et formater manuellement les réponses HTTP? L'API Java SE encapsule bien la fonctionnalité du client HTTP dans HttpURLConnection, mais existe-t-il un analogue pour la fonctionnalité du serveur HTTP?
Juste pour être clair, le problème que j'ai avec beaucoup d'exemples ServerSocket que j'ai vus en ligne est qu'ils font leur propre formatage de requête / réponse et traitement des erreurs, ce qui est fastidieux, sujet aux erreurs et peu susceptible d'être exhaustif, et j'essaye de l'éviter pour ces raisons.
Comme exemple de la manipulation HTTP manuelle que j'essaie d'éviter:
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html
la source
Réponses:
Depuis Java SE 6, il existe un serveur HTTP intégré dans
SunOracle JRE. Lecom.sun.net.httpserver
résumé du package décrit les classes impliquées et contient des exemples.Voici un exemple de lancement copypasté à partir de leurs documents (pour toutes les personnes qui essaient de le modifier néanmoins, car c'est un morceau de code laid, veuillez ne pas le faire, c'est un copier-coller, pas le mien, de plus vous ne devriez jamais modifier les citations à moins qu'elles aient changé dans la source d'origine). Vous pouvez simplement le copier / coller / exécuter sur Java 6+.
Il convient de noter que la
response.length()
partie de leur exemple est mauvaise, elle aurait dû l'êtreresponse.getBytes().length
. Même dans ce cas, lagetBytes()
méthode doit spécifier explicitement le jeu de caractères que vous spécifiez ensuite dans l'en-tête de réponse. Hélas, quoique peu judicieux pour les débutants, ce n'est après tout qu'un exemple de base du coup d'envoi.Exécutez-le et accédez à http: // localhost: 8000 / test et vous verrez la réponse suivante:
En ce qui concerne l'utilisation des
com.sun.*
classes, notez que cela, contrairement à ce que certains développeurs pensent, n'est absolument pas interdit par la FAQ bien connue Pourquoi les développeurs ne devraient pas écrire de programmes qui appellent des packages 'sun' . Cette FAQ concerne lesun.*
package (tel quesun.misc.BASE64Encoder
) à usage interne par Oracle JRE (qui tuerait ainsi votre application lorsque vous l'exécutez sur un autre JRE), pas lecom.sun.*
package. Sun / Oracle vient également de développer des logiciels en plus de l'API Java SE eux-mêmes comme toutes les autres sociétés telles qu'Apache, etc. L'utilisation decom.sun.*
classes n'est déconseillée (mais pas interdite) lorsqu'elle concerne une implémentation d'une certaine API Java, comme GlassFish (implément Java EE), Mojarra (impl JSF), Jersey (impl JAX-RS), etc.la source
sun.*
aveccom.sun.*
. Par exemple, voyez-vous de la documentation sur l'sun.*
API? Regardez ici: java.sun.com/products/jdk/faq/faq-sun-packages.html Cela dit -il quelque chosecom.sun.*
? Lecom.sun.*
est juste utilisé pour leur propre logiciel public qui ne fait pas partie de l'API Java. Ils développent également des logiciels en plus de l'API Java, comme toutes les autres sociétés.@jdk.Exported
dans le code source d'OpenJDK, ce qui signifie que l'API est considérée comme publique et sera disponible sur Java 9 (certains autrescom.sun.*
packages deviendront indisponibles en raison de Project Jigsaw).Découvrez NanoHttpd
"NanoHTTPD est un serveur HTTP léger conçu pour être intégré dans d'autres applications, publié sous une licence BSD modifiée.
Il est en cours de développement chez Github et utilise Apache Maven pour les builds et les tests unitaires "
la source
GET /../../blahblah http/1.1
est émise et le serveur passe au-dessus de la racine du site Web et dans le fichier système, servant des fichiers qui peuvent être utilisés pour compromettre ou attaquer à distance le système, comme un fichier de mot de passe.La solution com.sun.net.httpserver n'est pas portable entre les JRE. Il vaut mieux utiliser l'API webservices officielle dans javax.xml.ws pour amorcer un serveur HTTP minimal ...
EDIT: cela fonctionne réellement! Le code ci-dessus ressemble à Groovy ou quelque chose. Voici une traduction en Java que j'ai testée:
la source
text/xml
.J'aime cette question car c'est un domaine où il y a une innovation continue et il y a toujours un besoin d'avoir un serveur léger surtout quand on parle de serveurs embarqués dans des petits (er) appareils. Je pense que les réponses se répartissent en deux grands groupes.
Bien que je puisse considérer les bibliothèques HTTP comme: Jetty , Apache Http Components , Netty et d'autres comme des installations de traitement HTTP brutes. L'étiquetage est très subjectif et dépend du genre de choses que vous avez été invité à livrer pour les petits sites. Je fais cette distinction dans l'esprit de la question, en particulier la remarque sur ...
Ces outils bruts vous permettent de le faire (comme décrit dans d'autres réponses). Ils ne se prêtent pas vraiment à un style prêt à l'emploi pour créer un mini-serveur léger, intégré ou. Un mini-serveur est quelque chose qui peut vous offrir des fonctionnalités similaires à un serveur Web complet (comme, par exemple, Tomcat ) sans cloches et sifflets, faible volume, bonnes performances 99% du temps. Un serveur léger semble plus proche du phrasé d'origine un peu plus que brut, peut-être avec une fonctionnalité de sous-ensemble limitée, assez pour vous faire bien paraître 90% du temps. Mon idée de raw me ferait bien paraître 75% - 89% du temps sans conception et codage supplémentaires. Je pense que si / quand vous atteignez le niveau des fichiers WAR, nous avons laissé le "petit" pour les serveurs bonsi qui ressemble à tout ce qu'un gros serveur fait plus petit.
Options de serveur léger
Options de mini-serveur:
Entre autres choses à considérer, j'inclurais l' authentification, la validation, l'internationalisation, en utilisant quelque chose comme FreeMaker ou un autre outil de modèle pour rendre la sortie de la page. Sinon, la gestion de l'édition et du paramétrage HTML est susceptible de faire ressembler le travail avec HTTP à des noughts-n-crosses. Naturellement, tout dépend de la flexibilité dont vous avez besoin. S'il s'agit d'un télécopieur piloté par menu, cela peut être très simple. Plus il y a d'interactions, plus votre framework doit être « épais ». Bonne question, bonne chance!
la source
Jetez un oeil sur le serveur Web « jetée » jetée . Superbe logiciel Open Source qui semblerait répondre à toutes vos exigences.
Si vous insistez pour lancer le vôtre, jetez un œil à la classe "httpMessage".
la source
Il était une fois je cherchais quelque chose de similaire - un serveur HTTP léger mais entièrement fonctionnel que je pouvais facilement intégrer et personnaliser. J'ai trouvé deux types de solutions potentielles:
Alors ... je me suis mis à écrire JLHTTP - Le serveur HTTP léger Java .
Vous pouvez l'intégrer dans n'importe quel projet en tant que fichier source unique (s'il est plutôt long) ou en tant que fichier ~ 50K (~ 35K supprimé) sans dépendances. Il s'efforce d'être conforme à la RFC et comprend une documentation complète et de nombreuses fonctionnalités utiles tout en minimisant les ballonnements.
Les fonctionnalités incluent: hôtes virtuels, service de fichiers à partir du disque, mappages de types MIME via le fichier mime.types standard, génération d'index de répertoire, fichiers de bienvenue, prise en charge de toutes les méthodes HTTP, ETags conditionnels et prise en charge des en-têtes If- *, codage de transfert par blocs, gzip / dégonflage compression, HTTPS de base (tel que fourni par la JVM), contenu partiel (continuation du téléchargement), gestion des données en plusieurs parties / formulaire pour les téléchargements de fichiers, plusieurs gestionnaires de contexte via API ou annotations, analyse des paramètres (chaîne de requête ou x-www-form-urlencoded corps), etc.
J'espère que d'autres le trouveront utile :-)
la source
Un serveur web très basique écrit en java peut être trouvé ici http://library.sourcerabbit.com/v/?id=19
la source
Spark est le plus simple, voici un guide de démarrage rapide: http://sparkjava.com/
la source
Il est possible de créer un httpserver qui fournit un support de base pour les servlets J2EE avec juste le JDK et l'api du servlet en quelques lignes de code.
J'ai trouvé cela très utile pour tester des servlets, car il démarre beaucoup plus rapidement que d'autres conteneurs légers (nous utilisons la jetée pour la production).
La plupart des httpservers très légers ne prennent pas en charge les servlets, mais nous en avons besoin, j'ai donc pensé partager.
L'exemple ci-dessous fournit une prise en charge de base de servlet, ou jette et UnsupportedOperationException pour des éléments non encore implémentés. Il utilise com.sun.net.httpserver.HttpServer pour le support http de base.
la source
Je peux fortement recommander d'étudier Simple , surtout si vous n'avez pas besoin des fonctionnalités de Servlet, mais accédez simplement aux objets request / reponse. Si vous avez besoin de REST, vous pouvez mettre Jersey dessus, si vous avez besoin de sortir du HTML ou similaire, il y a Freemarker. J'aime vraiment ce que vous pouvez faire avec cette combinaison, et il y a relativement peu d'API à apprendre.
la source
Ce code est meilleur que le nôtre, il vous suffit d'ajouter 2 bibliothèques : javax.servelet.jar et org.mortbay.jetty.jar .
Jetée de classe:
Classe de servlet:
la source
*.Servlet.jar
et ne*.jetty.jar
font évidemment pas partie de Java SE.Vous pouvez également consulter un cadre d'application NIO tel que:
la source
Toutes les réponses ci-dessus fournissent des détails sur le gestionnaire de requêtes à thread unique principal.
réglage:
Permet de servir plusieurs requêtes via plusieurs threads en utilisant le service exécuteur.
Ainsi, le code de fin sera quelque chose comme ci-dessous:
la source
caisse Simple . C'est un serveur intégrable assez simple avec un support intégré pour une grande variété d'opérations. J'aime particulièrement son modèle de filetage ..
Incroyable!
la source
Découvrez
takes
. Regardez https://github.com/yegor256/takes pour des informations rapidesla source
Que diriez- vous du projet Apache Commons HttpCore ?
Depuis le site Web: ... Objectifs HttpCore
la source
Essayez ceci https://github.com/devashish234073/Java-Socket-Http-Server/blob/master/README.md
Cette API a créé un serveur HTTP à l'aide de sockets.
Par exemple, voici comment le constructeur de la
Response.java
classe convertit une réponse brute en réponse http:la source
Vous pouvez écrire un serveur Java Jetty intégré assez simple .
Embedded Jetty signifie que le serveur (Jetty) est livré avec l'application au lieu de déployer l'application sur un serveur Jetty externe.
Donc, si dans l'approche non intégrée, votre application Web intégrée au fichier WAR déployé sur un serveur externe ( Tomcat / Jetty / etc), dans la jetée intégrée, vous écrivez l'application Web et instanciez le serveur de la jetée dans la même base de code.
Un exemple de serveur Java Jetty intégré que vous pouvez git cloner et utiliser: https://github.com/stas-slu/embedded-jetty-java-server-example
la source