Como posso usar o openssl para obter resultados de solicitações HTTP GET?

4

Eu preciso usar o openssl para executar algumas solicitações HTTP GET em um script de shell. A linha que estou usando para fazer isso agora é mostrada abaixo. Isso está analisando o conteúdo de uma resposta XML dos seguintes formatos.

<Result>success</Result>

<Result>failure</Result>

echo -e "GET /test HTTP/1.1\r\nHost:$(hostname)\r\n\r\n" | openssl 2>&1 s_client -quiet -connect server-url:443 | grep -o -P --color '(?<=Result\>).*(?=\</Result)'

Isso funciona e retorna a string 'sucesso' ou 'falha' de acordo. O problema que estou enfrentando é que o comando openssl não termina depois de fazer a solicitação GET, mas fica lá esperando mais entradas. Acredito que isso se deva ao -ign_eof implícito que impede a finalização automática causada pela opção -quiet . Eu tentei usar a opção -no_ign_eof , mas isso faz com que o comando openssl termine antes que a solicitação GET tenha recebido uma resposta, então não consigo obter o conteúdo da resposta se eu usar isso.

Como eu posso modificar este comando para que eu possa passar a requisição GET através de stdin (requerido como eu quero colocar isto em um loop) mas ter o comando openssl terminado após cada requisição?

    
por conorgriffin 23.10.2015 / 18:08

2 respostas

3

O que você realmente deve fazer é usar uma ferramenta projetada para buscar recursos da Web, como curl , wget ou o comando GET de libwww-perl. Se nada estiver disponível, o administrador do sistema deverá instalar algo apropriado.

Com isso fora do caminho ...

O comando openssl não termina porque o servidor web não fechou a conexão.

Lembre-se de que, por padrão, o HTTP mantém as conexões abertas após cada solicitação como uma otimização de desempenho. Quando uma solicitação é concluída, outra solicitação pode ser enviada pela mesma conexão, em vez de fechar e reabrir uma nova conexão.

Se você quiser instruir o servidor a fechar a conexão, envie o cabeçalho Connection: close HTTP.

    
por 23.10.2015 / 18:43
-1

Outra solução simples (mas provavelmente pior) seria usar HTTP / 1.0 em vez de HTTP / 1.1.

    
por 30.10.2018 / 17:59