HAProxy quebra a solicitação HTTP

Question

HAProxy quebra a solicitação HTTP

#1 resposta do (1 votos)

1

Eu não tenho certeza do que está acontecendo aqui. Eu fiz uma pequena coisa da Internet das coisas um tempo atrás, que cria solicitações HTTP que se parecem com:

POST /update.py HTTP/1.1
Host: iot.example.com
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: [...]

iv=[...]&msg=base64(encrypted_msg)

E um script Python do lado do servidor correspondente que extraiu informações dos dados do POST. Eu recentemente mudei o proxy reverso do meu firewall do squid para o HAProxy e, de repente, o Apache está retornando HTTP 400 statuses, seinly antes que o dispositivo IOT tenha a chance de enviar os dados do POST. Aqui está um stream TCP wireshark de uma dessas interações:

POST /update.py HTTP/1.1
Host: iot.example.com
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
X-Forwarded-Proto: http
X-Forwarded-For: xx.xx.xx.xx

HTTP/1.1 400 Bad Request
Date: Sat, 17 Jun 2017 22:29:45 GMT
Server: Apache/2.4.25 (FreeBSD) mod_wsgi/4.5.15 Python/2.7
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
iv=En98cormFMA7NO5e-4qh2Q==&msg=ek_JDRJPqPUvNlztUVH6FTtfVVdHgODWMimBcZklos2XntlMOM1RweBjsp5z-zY=

Nota: Tudo entre o HTTP/1.1 400 Bad Request e </html> são respostas do servidor, tudo o mais é o que o servidor está recebendo. Os cabeçalhos X-Forwarded * foram definidos pelo HAProxy. Tanto quanto eu sei que o Squid não usou estes

O mais estranho é que o Apache está respondendo mesmo antes de obter os dados do POST. O servidor responde bem às solicitações GET , e eu estou executando alguns outros servidores Apache atrás do mesmo firewall que parece funcionar. A única diferença real em que consigo pensar é que essas solicitações HTTP são bastante codificadas para o microcontrolador de onde elas vêm, e talvez elas não estejam bem no começo. Qualquer sugestão seria muito apreciada. Obrigado antecipadamente!

apache-2.4 http

por jmp 18.06.2017 / 01:04

1 resposta

Tags apache-2.4 http

yum update falha Erro: Não é possível recuperar os metadados do repositório (repomd.xml) para o repositório: powerstack. Por favor, verifique o seu caminho e tente novamente A interface secundária não recebe tráfego UDP para o aplicativo *: PORT

score 1 · Accepted Answer

Acontece que o problema foi o fim da linha em minhas solicitações HTTP. Eu estava enviando uma mistura de LF e CRLF. O RFC2616 requer que o HTTP / 1.1 use somente CRLF, mas também declara que servidores devem implementar uma "provisão de tolerância" . No entanto, o Apache > = 2.4.25 assume como padrão HttpProtocolOptions Strict , o que retorna um status HTTP/1.1 400 para todos os cabeçalhos malformados.

O FreeBSD já empacotou o Apache 2.4.25 desde dezembro, mas eu assumo que o Squid estava regularizando cabeçalhos para mim porque não quebrou então. Eu acho que o HAProxy é mais laissez-fare, então a mudança do Squid para o HAProxy expôs o servidor ao meu antigo bug de firmware.

A correção correta seria reativar o microcontrolador com o firmware atualizado, mas isso é um aborrecimento. Uma solução rápida e suja é dizer ao Apache para relaxar. Adicionar HttpProtocolOptions Unsafe a httpd.conf é uma "correção" rápida e, pelo menos, recupera o registro de dados por enquanto.