Bem, após testes rápidos em alguns servidores aleatórios contendo Server: Apache-Coyotte
assinatura de cabeçalhos em suas respostas HTTP, parece que você está certo ao enviar get / HTTP/1.1\r\nHost: <target_IP>\r\n\r\n
com uma conexão netcat simples toda vez que um código HTTP 400 deveria ter sido recebido .
Por exemplo:
$ { echo -en "get / HTTP/1.1\r\nHost: <target_IP>:8080\r\n\r\n" ; } | nc <target_IP> 8080
01:14:58.095547 IP 192.168.1.3.57245 > <target_IP>.8080: Flags [P.], seq 1:42, ack 1, win 115, options [nop,nop,TS val 4294788321 ecr 0], length 41
E..]C.@[email protected].......
..D.....get / HTTP/1.1
Host: <target_IP>:8080
[...]
01:14:58.447946 IP <target_IP>.8080 > 192.168.1.3.57245: Flags [.], seq 1:1409, ack 43, win 65494, options [nop,nop,TS val 7981294 ecr 4294787971], length 1408
E...f...i.....p.............A..............
.y....C.HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=ISO-8859-1
Transfer-Encoding: chunked
Date: Tue, 27 Jan 2015 00:15:14 GMT
Devo dizer que estou um pouco chocado aqui e não ficaria surpreso em ver esse comportamento estendido a todos os métodos HTTP / 1.1 nesse caso.
Você deve preencher um relatório de bug na sua ferramenta de acompanhamento de bugs e enviar um e-mail para o lista de e-mails porque essa é uma violação feia do RFC 2616 (veja abaixo) com más conseqüências.
5.1.1 Method
The Method token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token