“Exception socketexception: fin de fichier Inattendue du serveur” à partir de servlet, mais pas à partir de l'application autonome

Je voudrais appeler une servlet à partir de mon servlet. Je peux appeler la télécommande servlet à partir d'une application autonome, mais je ne peut pas l'appeler de ma servlet (c'est sur Glassfish). J'utilise exactement le même code pour l'appel (je reçois le message d'erreur à la dernière ligne de code):

URL serverAddress = new URL(endpoint);
//Set up the initial connection
HttpURLConnection connection = (HttpURLConnection) serverAddress.openConnection();
connection.setRequestMethod("POST");
connection.setDoOutput(true);
connection.setDoInput(true);
connection.setReadTimeout(timeOut);
connection.setRequestProperty("Content-Type", "text/xml; charset=ISO-8859-1");
connection.connect();
OutputStreamWriter wr = new OutputStreamWriter(connection.getOutputStream());
wr.write(requestBody);
wr.flush();
BufferedReader rd = new BufferedReader(new InputStreamReader(connection.getInputStream()));

Il est douteux que ce code ne peut pas lire la réponse de la télécommande servlet donc probablement la servlet n'a pas réponse à tout. Cependant pourquoi ne fait-il répondre quand je l'appelle il de standlone application? Je ne comprends vraiment pas...
J'ai eu cette exception:

java.net.SocketException: Unexpected end of file from server
    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1049)

Quelqu'un a une idée? Est-il possible qu'il existe des restricitions pour les servlets ne pas utiliser le HttpURLConnection? Merci!

Est "point de terminaison" vraiment la même dans les deux cas?

OriginalL'auteur Viktor | 2012-06-29

  1. 4

    Cela pourrait être dû au fait que la Content-Length en-tête n'est pas définie. Et parce que la Fin de la POST du corps de la requête n'est pas envoyé. Le serveur est de se retrouver en attendant l'expiration de la fin du flux.

    Vous devriez essayer ces deux choses pour le faire fonctionner:

    • Définir le contenu de la longueur d'en-tête avec le corps de la requête de la taille avant de faire connect()
    • Essayez de fermer le connection.getOutputStream().close() qui envoient la fin de la requête POST.

    OriginalL'auteur Ramesh PVK

  2. 3

    regardez l'url que vous frapper.
    j'ai eu le même problème et après beaucoup de régression est venu de savoir que les url générées et que le fait d'être frappé avait un espace vide et c'était la cause du problème, résolu par le remplacement de space avec underscore

    Vous pouvez aussi encoder l'url en appelant URIEncoder.encode(uri); rappelez-vous que seule la partie de l'uri après ? est doit être codé.

    Pour moi, c'est un paramètre de l'URL qui contient l'espace de caractère! 🙁 J'ai dû utiliser URLEncoder.encoder pour le paramètre pour le convertir web format convivial !! 🙂 merci

    OriginalL'auteur moCap

  3. 0

    Dans notre cas, c'était tomcat ensemble de http2 protocole (supprimé forçant à http2 protocole par défaut,
    supprimer
    <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
    de server.xml dans tomcat config dossier
    mais le client http1.1, aussi java devait être signé avec certificat (keyimport outil), donc la question sous-jacente est un peu délicat....

    OriginalL'auteur blackuprise