У меня есть API со следующим стеком:
Sinatra <=HTTPS/TLS=> Nginx <=HTTPS/TLS=> ALB(ELBv2)
Это базовый сокращатель URL-адресов, который отправляет 301 редирект в браузер для перехода на более длинный URL-адрес. Это работало безупречно год или два, но, начиная с Chrome 58, я теперь получаю ERR_SPDY_PROTOCOL_ERROR при перенаправлении из API в Chrome. Обычные страницы возвращаются нормально, а другие браузеры работают нормально. Ответ определенно отправляется ALB, поскольку я вижу поток трафика, и в CloudWatch или в журналах для Nginx или Sinatra ошибок нет.
Я открыл заявку в AWS Support, но от нее мне мало пользы. Кто-нибудь еще видел нечто подобное? Я даже не уверен, что это исправить, поскольку мой nginx даже не настроен на использование SPDY или HTTP2.
РЕДАКТИРОВАТЬ: Вот пример журнала доступа ALB для сломанной попытки и рабочего (через 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"
РЕДАКТИРОВАТЬ 2:
Обработанный пример вывода команды curl -vvv:
Мы столкнулись с этой проблемой только сейчас. Наше приложение устанавливало заголовок Content-Length и использовало gzip. Очевидно http / 2 не любит эту комбинацию!
Удалено "Content-Length", и все работает.