2016-06-24 5 views
0

Je suis à la recherche d'une bibliothèque d'analyse/rendu HTTP asynchrone qui peut être connectée à un flux d'octets (elle ne dépend pas de l'accès direct au socket et ne crée pas de les connexions de réseau).Bibliothèque d'analyseurs/analyseurs HTTP pour Java/Scala

Fondamentalement donné un flux d'octets que je veux être en mesure d'analyser une requête HTTP à partir de celui-ci, potentiellement manipuler quelque chose et le rendre à une chaîne d'octets. À la fois pour les demandes et les réponses. Idéalement pour les demandes strictes et segmentées.

En principe un proxy Http de manipulation qui fonctionne sur les flux d'entrée, les flux java, les flux réactifs ou quelque chose de similaire (serveur client &).

quelque chose comme ceci:

stream of bytes <-> HttpLib <-> customCode <-> HttpLib <-> stream of bytes 

jusqu'à présent, je regardé

  • Akka Http: proche de ce que j'ai besoin, mais le comportement d'erreur est codé en dur
  • Appache Http Composants: semble être orienté vers l'utilisation avec des prises, les niveaux inférieurs sont accessibles mais il ne se sent pas comme l'utilisation prévue
  • d'autres pulvérisent, netty pas sûrs s'ils feraient n'importe quelle expérience ce?

Toutes les suggestions sont les bienvenues!

Mise à jour

En ce qui concerne Akka HTTP: Je veux dire le comportement de onUpstreamFailure, qui est gérée directement dans le plan de serverLayer. Je suppose que c'est la valeur par défaut la plus efficace/pratique, mais comment les niveaux de flux pourraient-ils réagir après que le serverLayer réagisse à de telles erreurs (éventuellement) la propagation de l'erreur serait plus flexible.

-> Bytes -> serverLayer -> customCode 
       | 
    <- (error response) 
+0

Akka HTTP est aussi la première chose qui viendrait à mon mind (http://doc.akka.io/docs/akka/2.4.7/scala/http/low-level-server-side-api.html#Request-Response_Cycle). En quoi la gestion des erreurs est-elle trop restrictive pour votre scénario d'utilisation? – devkat

+0

Pouvez-vous préciser ce que vous entendez par "mais le comportement d'erreur est codé en dur"? – tkachuko

Répondre

0

En cas où quelqu'un tombe par hasard sur la question

  • HTTP Akka serait un excellent choix dans le travail général juste doens't que bien pour nous (voir la question)
  • Netty fournit EmbeddedChannels qui permet exécuter des analyseurs/rendus/décodeurs HTTP sans se lier à un socket. Je pense que ceci est principalement destiné aux tests mais n'est pas dans les paquets .test et peut également être utilisé pour l'implémentation de codecs de niveau supérieur (documentation Netty 3.x)