MSIE $ .ajax задерживается в решении Heroku SSL Rails

Question

У нас есть приложение Rails 3 на Heroku, которое страдает от длительных задержек при запросах JQuery AJAX в IE11, в частности, - примерно 4 или 5 секунд. Запросы не терпят неудачу; они просто берут навсегда. Цивилизованные браузеры, такие как Chrome, FF & Safari все реагируют в течение секунды. И я вижу, что время ответа на сервере такое быстрое, но IE занимает 4-5 секунд, чтобы показать, что запрос завершен.

У меня есть приложение для баребон, чтобы продемонстрировать: https://ajax-testing.herokuapp.com/test. Щелчок по тексту отправляет запрос AJAX на сервер, который отгоняет его, и он отображается в сообщении. Я считаю, что это быстро во всех браузерах, кроме IE, где вы не видите предупреждение в течение 5 секунд.

Я не испытываю задержек, когда я тестирую локально, но когда он развертывается в Heroku, я делаю. Я определил, что это имеет какое-то отношение к SSL на Heroku, потому что проблема уходит, если я установил config.force_ssl в false. Единственная реальная разница в заголовках между SSL (с задержками) и не-SSL (без задержек) на Heroku - это заголовок Strict-Transport-Security в версии SSL.

Вот код для запроса AJAX ...

$.ajax({ 
    type: "POST", 
    url: "ajax_call", 
    dataType: 'json', 
    data: { message: "Test message" } 
    }).done(function(data) { 
    alert(data["message"]); 
    }); 

Setup:

• Rails 3.2.21 на Heroku
• JQuery 1.11.1
• Пробовал как тонкий & единорог
• IE 11.0.9600.17633 (обновление 11.0.16)

Я пробовал разные серверы, вынимая dataType и другие вариации $ .ajax, добавляя метатеги IE и т. Д. Я не могу найти ссылку на эту конкретную проблему в Интернете. У кого-нибудь есть предложения относительно того, что это может быть или как сузить его дальше?

Answer 1

Это оказалось проблемой Heroku из-за ошибки в недавнем обновлении балансировки нагрузки. Я потратил огромное количество времени на это, исходя из предположения, что это вызвано недавним обновлением IE, которое совпало с первыми сообщениями о проблеме, и поскольку IE был единственным браузером, затронутым в наших тестах.

Когда я увидел проблемы с исполнением JavaScript, моя первая мысль не была: проверьте ELB - но это, вероятно, должно было быть;) Это первый раз, когда мы отключили наши приложения из-за Heroku/Amazon Обновить.

По-видимому, проблема возникает при запросах, у которых нет заголовков Content-Length или Transfer-encoding: chunked, и это может повлиять только на определенные конфигурации стека, иначе я бы подумал, что смог бы найти больше отчетов об этом.

Если вы столкнулись с этим, создайте справочный билет и сообщите им, что у вас есть задержка IE в вашем приложении, и вы считаете, что это связано с недавним обновлением ELB. Они могут развернуть обновление для ELB для своих приложений, что они и сделали для нас, и в конечном итоге это сделает для всех приложений Heroku.

Answer 2

В моем случае я использовал Rails с единорогом на Heroku со всеми страницами под SSL. Они предлагают установить RACK_ENV=deployment, чтобы заставить единорога загрузить Rack::ContentLength и Rack::Chunked middlewares (или вручную добавить их самостоятельно). Это устранило проблему для меня, не требуя, чтобы они специально развертывали обновление для моего приложения.

Answer 3

Спасибо за эту тему, мы были очень близки к тому, чтобы тратить много времени на это. Мы просто включили Rack :: Deflate, но откат назад не разрешил это. Мы также работаем под HTTPS.

ответ Heroku был:

Недавно мы обнаружили, что это из-за поведения веб-сервера Unicorn + Heroku по умолчанию RACK_ENV = производство. Вы должны использовать Unicorn с RACK_ENV = развертывание (см. https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L56-L79 для более подробной информации), или вы должны использовать Unicorn с серверами HTTP, такими как nginx.

Оба они решают проблему, которая у вас есть сейчас.

Эта проблема возникает из-за того, что ваш ответ не содержит заголовка Content-Length или Transfer-encoding: chunked. Это не недопустимый HTTP-ответ, но он не является хорошим ответом HTTP, и вы хотите его исправить. Вы также можете вручную добавить промежуточное программное обеспечение, такое как Rack :: ContentLength и/или Rack :: Chunked.

Кроме того, вы можете переключиться на Puma (https://github.com/defunkt/unicorn/blob/master/lib/unicorn.rb#L56-L79, который является нашим рекомендуемым веб-сервером сейчас).

Я добавил Rack :: Chunked, чтобы выйти из Dodge сейчас. Rack :: Deflate strips заголовок contentLength, который я считаю.

Я действительно не знал о параметрах RACK_ENV, но I'm not alone there!

Я предполагаю, что обновление RACK_ENV и переход на Puma - это следующий шаг.