A API Sinatra / Nginx / ELBv2 está gerando ERR_SPDY_PROTOCOL_ERROR somente no Chrome 58 ou superior

Question

Eu tenho uma API com a seguinte pilha:

Sinatra <=HTTPS/TLS=> Nginx <=HTTPS/TLS=> ALB(ELBv2)

É um encurtador de URL básico que envia um redirecionamento 301 para o navegador para ir para o URL mais longo. Isso funcionou perfeitamente por um ano ou dois, mas, desde o Chrome 58, agora recebo ERR_SPDY_PROTOCOL_ERROR nos redirecionamentos da API no Chrome. Páginas regulares retornam muito bem, e outros navegadores funcionam bem. A resposta é definitivamente enviada pelo ALB, como vejo o fluxo de tráfego, e não há erros relatados no CloudWatch ou nos logs para Nginx ou Sinatra.

Eu abri um ticket com o AWS Support, mas não consegui muito dele. Alguém viu algo parecido? Eu nem tenho certeza do que tentar consertar, já que meu nginx não está configurado para usar SPDY ou HTTP2.

EDIT: Aqui está um log de acesso de amostra ALB para a tentativa quebrada e um trabalho (via curl):

h2 2017-06-21T15:30:01.438546Z app/aws-example-net/019315b3036f76ac 184.75.37.61:59367 10.252.14.202:443 0.000 0.004 0.000 301 301 30 1170 "GET https://aws.example.net:443/short/-OpLPG8h HTTP/2.0" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.104 Safari/537.36" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-1:XXXXXXXXXXXX:targetgroup/ecs-prod-e-urlshortener/7c6cddcc83c91aeb "Root=1-594a90f9-41b321bf039f142a083cb587"
h2 2017-06-21T15:30:06.928711Z app/aws-example-net/019315b3036f76ac 184.75.37.61:19376 10.252.14.202:443 0.000 0.004 0.000 301 301 46 1170 "GET https://aws.example.net:443/short/-OpLPG8h HTTP/2.0" "curl/7.50.1" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-1:XXXXXXXXXXXX:targetgroup/ecs-prod-e-urlshortener/7c6cddcc83c91aeb "Root=1-594a90fe-2f1b92043fe3030461e84219"

EDIT 2:

Exemplo de saída sanitizada de curl -vvv:

link

    

Answer 1

Nós nos deparamos com esse problema agora. Nosso aplicativo estava definindo o cabeçalho "Content-Length" e usando o gzip. Aparentemente o http / 2 não gosta dessa combinação!

Removido "Content-Length" e funciona.