telnet enviar una solicitud HTTP

estoy usando telnet para enviar una petición HTTP, como esto:telnet enviar una solicitud HTTP

telnet> open 192.168.4.135 8087 
Trying 192.168.4.135... 
Connected to 192.168.4.135. 
Escape character is '^]'. 
POST /rpc/ HTTP/1.1 
HOST:192.168.4.135:8087 
Content-length:18 
Content-type:application/x-http-form-urlencoded 

action=loadrsctype 
HTTP/1.1 200 OK 
Date: Thu, 17 May 2012 03:52:53 GMT 
Content-Length: 45 
Content-Type: text/html; charset=ISO-8859-1 

return=fail&error=Configuration doesn't existHTTP/1.1 400 Bad Request 
Content-Type: text/html 
Connection: close 
Date: Thu, 17 May 2012 03:52:53 GMT 
Content-Length: 94 

<HTML><HEAD> 
<TITLE>400 Bad Request</TITLE> 
</HEAD><BODY> 
<H1>Bad Request</H1> 
</BODY></HTML> 
Connection closed by foreign host.

el código de respuesta es 200, pero ¿por qué hay un párrafo así:

HTTP/1.1 400 Bad Request 
Content-Type: text/html 
Connection: close 
Date: Thu, 17 May 2012 03:52:53 GMT 
Content-Length: 94 

<HTML><HEAD> 
<TITLE>400 Bad Request</TITLE> 
</HEAD><BODY> 
<H1>Bad Request</H1> 
</BODY></HTML>

Esta es la salida del servidor o telnet en sí? ¿Cómo evitar mostrar esto?

--actualización-- Cuando cambio "HTTP/1.1" a "http/1.1", obtengo la respuesta correcta. Ahora me pregunto si esto es un requisito de protocolo o está relacionado con la implementación del servidor.

Fuente

2012-05-17 Fei Xue

Parece que el contenido de la respuesta "200 OK" es "return = fail & error = La configuración no existe", por lo que no parece que esto haya funcionado. ¿Estás seguro de que la URL está bien? –

Creo que la url no tiene ningún problema. Parece que hay DOS respuestas. El primero (return = fail & error = Configuration no existe) es lo que esperaba, pero el segundo no. –

El código en la URL que está accediendo está imprimiendo un texto:

return=fail&error=Configuration doesn't exist

Pero entonces su código continúa para imprimir un error HTTP 400. Probablemente olvidó abortar después de imprimir la respuesta, por lo que su código también imprime el HTTP 400.

Fuente

2012-05-17 04:20:04 Malvineous

así que, realmente creo que el problema es el servidor. –

@ccsnailpp: Sí, el problema es que el código en el servidor tiene un error. (¡Lo siento, estaba asumiendo que era tu código ejecutándose en el servidor!) – Malvineous

sí, debería ser. el servidor no es ni apache ni nginx. es un pequeño servidor implementado por nuestro equipo. –

-1

Intente reemplazar & con &.

Fuente

2013-02-15 15:44:41 gogol

En HTTP 1.1, todas las conexiones se consideran persistent a menos que se especifique lo contrario.

Entonces ... Creo que el servidor está recibiendo algún tipo de char de espurio falso y responde con un Bad Request.

Si utiliza http/1.1 en lugar de HTTP/1.1 podría hacer que la versión de repliegue a la versión 1.0 que no es persistente por defecto y después de la respuesta 200 OK de terminar la conexión.

Fuente

2013-02-15 16:01:28

Respuesta

Cuestiones relacionadas