Про що йдеться :: ERR_HTTP2_PROTOCOL_ERROR?

Зараз я працюю над веб-сайтом, який викликає net::ERR_HTTP2_PROTOCOL_ERROR 200помилку в Google Chrome. Я не впевнений, що саме може спровокувати цю помилку, я помітив, що вона вискакує лише під час доступу до веб-сайту в HTTPS. Я не можу бути на 100% впевнений, що це пов'язано, але, схоже, це заважає виконувати JavaScript належним чином.

Наприклад, трапляється такий сценарій:

1. Я переходжу на веб-сайт у HTTPS

2. Моя стрічка Twitter, інтегрована через https://publish.twitter.com, взагалі не завантажується

3. Я можу помітити в консолі ERR_HTTP2_PROTOCOL_ERROR

4. Якщо я видаляю код для завантаження каналу Twitter, помилка залишається

5. Якщо я заходжу на веб-сайт у HTTP, з'являється канал Twitter, і помилка зникає

Google Chrome - єдиний веб-браузер, який викликає помилку: він добре працює як на Edge, так і на Firefox. (NB: Я спробував із Safari, і у мене схожа kcferrordomaincfnetwork 303помилка)

Мені було цікаво, чи може це бути пов’язано із заголовком, поверненим сервером, оскільки в помилці є згадка про «200», а сторінка 404/500 нічого не викликає.

Справа в тому, що помилка взагалі не задокументована. Пошук у Google дає мені дуже мало результатів. Більше того, я помітив, що це з’являється у зовсім останніх випусках Google Chrome; помилка не з’являється на v.64.X, але вона працює на v.75 + (незалежно від ОС; я працюю на Mac tho).

Будь-яка підказка в цьому пункті для дослідження буде рада оцінити!

Заздалегідь спасибі.

Трістан

Редагувати 1: Можливо, це стосується веб-сайту OK на Firefox, але не на Safari (помилка kCFErrorDomainCFNetwork 303), а також Chrome (нетто: ERR_SPDY_PROTOCOL_ERROR)

Редагувати 2: Результати подальших розслідувань такі:

• помилка не з’являється на тій самій сторінці, якщо сервер повертає 404 замість 2XX
• помилка не з’являється на локальному рівні із сертифікатом HTTPS
• помилка з'являється на іншому сервері (обидва - OVH), який використовує інший сертифікат
• помилка з'являється незалежно від того, яка версія PHP використовується, від 5,6 до 7,3 (використовується фреймворк: Cakephp 2.10)

Редагування 3: За запитом, нижче знаходиться повертається заголовок невдалого ресурсу, який є всією веб-сторінкою. Навіть якщо помилка спрацьовує на кожній сторінці з HTTP-заголовком 200, ці сторінки завжди завантажуються у веб-переглядачі клієнта, але іноді елемент відсутній (у моєму прикладі, зовнішній канал Twitter). Кожен інший актив на вкладці "Мережа" має повернення успіху, за винятком самого документа.

Заголовок Google Chrome (з помилкою):

Заголовок Firefox (без помилки):

curl --head --http2Запит в консолі повертає наступний успіх:

HTTP/2 200 
date: Fri, 04 Oct 2019 08:04:51 GMT
content-type: text/html; charset=UTF-8
content-length: 127089
set-cookie: SERVERID31396=2341116; path=/; max-age=900
server: Apache
x-powered-by: PHP/7.2
set-cookie: xxxxx=0919c5563fc87d601ab99e2f85d4217d; expires=Fri, 04-Oct-2019 12:04:51 GMT; Max-Age=14400; path=/; secure; HttpOnly
vary: Accept-Encoding

Редагування 4: Спроба заглибитись у chrome: // net-export / та інструменти https://netlog-viewer.appspot.com повідомляють мені, що запит закінчується на RST_STREAM:

t=123354 [st=5170]    HTTP2_SESSION_RECV_RST_STREAM
                      --> error_code = "2 (INTERNAL_ERROR)"
                      --> stream_id = 1

Що я читав у цьому іншому дописі , " У HTTP / 2, якщо клієнт хоче відмовитись від запиту, він надсилає RST_STREAM. Коли сервер отримає RST_STREAM, він перестане надсилати DATA кадри клієнту, тим самим зупиняючи відповідь (або для завантаження). З'єднання все ще можна використовувати для інших запитів, і запити / відповіді, що супроводжуються тим, хто був перерваний, можуть продовжувати розвиватися. [...] Можливо, до моменту переходу RST_STREAM з клієнт на сервері, весь вміст запиту перебуває в транзиті і надійде до клієнта, який відкине його. Однак, для великого вмісту відповіді, надсилання RST_STREAM може мати хороші шанси прийти на сервер раніше, ніж цілий вміст відповіді надсилається, і тому буде збережено пропускну здатність. "

Описана поведінка така сама, як та, яку я можу спостерігати. Але це означатиме, що браузер є винуватцем, і тоді я б не зрозумів, чому це відбувається на двох однакових сторінках, на одній з 200 заголовок, а на іншій 404 (те саме стосується відключення JS).

Кілька тижнів мене також дратувала ця "помилка":

net :: ERR_HTTP2_PROTOCOL_ERROR 200

У моєму випадку це сталося на зображеннях, створених PHP.

Це було на header()рівні, а саме на цьому:

header ('Content-Length:'. Filesize($cache_file));

Очевидно, він не повернув точний розмір, тому я видалив його і зараз все працює нормально.

Отже Chrome перевіряє точність даних, що передаються через заголовки, і якщо вони не відповідають, вони виходять з ладу.

EDIT

Я з'ясував, чому content-lengthчерез " filesizeпрорахували": GZIPстиснення активне для файлів PHP, тому виключення відповідного файлу усуне проблему. Помістіть цей код у .htaccess:

SetEnvIfNoCase Request_URI ^ / thumb.php no-gzip -vary

Це працює, і ми тримаємо заголовок Content-length.

Я не зрозумів, що саме відбувається, але знайшов рішення.

Особливість CDN з OVH був винуватцем. У мене він був встановлений на моєму хост-сервісі, але відключений для мого домену, оскільки він мені не потрібен.

Якось, коли я це дозволяю, все працює.

Я думаю, що це змушує Apache використовувати протокол HTTP2, але те, що я не розумію, - це те, що дійсно була згадка HTTP2 у кожному з моїх заголовків, що, як я вважаю, означає, що сервер відповідав правильним протоколом.

Тож рішенням для мого дуже конкретного випадку було включити опцію CDN у всіх зацікавлених областях.

Якщо хтось краще розуміє, що могло статися тут, сміливо діліться поясненнями.

Я зіткнувся з цим, оскільки сервер http2 закрив з'єднання під час надсилання великої відповіді в Chrome.

Чому? Тому що це лише налаштування сервера http2, названого WriteTimeout .

У моєму випадку це було - на веб-сервері не залишилось місця на диску.

У мене виникла подібна проблема, я отримував ERR_HTTP2_PROTOCOL_ERROR на одному з HTTP GET запитів.

Я помітив, що оновлення Chrome очікує на розгляд, тому я оновив браузер Chrome до останньої версії, і помилка пішла наступного разу, коли я перезапустив веб-переглядач.

У мене була ця проблема, коли я мав сервер Nginx, який відкривав додаток node-js у зовнішній світ. Nginx зробив файл (css, js, ...) стиснутим разом gzipіз Chrome і виглядав так само.

Проблема вирішена, коли ми виявили, що сервер node-js також стискає вміст gzip. У чомусь це подвійне стискання призводить до цієї проблеми. Скасування стиснення node-js вирішило проблему.

Наразі ця помилка виправлена: https://chromium-review.googlesource.com/c/chromium/src/+/2001234

Але мені це допомогло, змінивши налаштування nginx:

• включення gzip;
• add_header 'Кеш-контроль' 'не-зберігання, без кешу, необхідно повторно підтвердити, переоцінити проксі, max-age = 0';
• закінчується;

У моєму випадку Nginx діє як зворотний проксі для програми Node.js.

Це сталося зі мною, коли я зареєстрував нове доменне ім’я, наприклад, "new" для example.com (new.example.com). Назву не вдалося тимчасово вирішити в моєму місці протягом декількох годин, тоді як її можна було вирішити за кордоном. Тож я використовував проксі для тестування веб-сайту, на якому я бачив net::ERR_HTTP2_PROTOCOL_ERRORхромовану консоль для деяких публікацій AJAX. Години пізніше, коли ім’я можна було змінити локально, ці помилки просто зникли.

Я думаю, що причиною цієї помилки є те, що запити AJAX не перенаправлені моїм проксі, він просто завітає на веб-сайт, який не був вирішений моїм місцевим DNS-рішенням.

Я стикався з цією помилкою кілька разів, і це було пов’язано з передачею великих ресурсів (більше 3 МБ) від сервера до клієнта.

У мене виникла та сама проблема (asp, c # - HttpPostedFileBase), коли розміщую файл розміром більше 1 МБ (хоча програма не має жодних обмежень щодо розміру файлу), для мене допомогло спрощення класу моделі. Якщо у вас виникла ця проблема, спробуйте видалити деякі частини моделі та подивіться, чи це допоможе яким-небудь чином. Звучить дивно, але працювало для мене.

Я останній тиждень відчував цю проблему, коли я намагався надсилати DELETE-запити на свій PHP-сервер через AJAX. Нещодавно я оновив мій план хостингу, де тепер у мене на хості є сертифікат SSL, який зберігає файли PHP та JS. З моменту додавання сертифіката SSL я більше не відчуваю цього питання. Сподіватися, що це допомагає у цій дивній помилці.

Я також стикався з цією помилкою, і я вважаю, що в цьому може бути кілька причин. Моє було, ARR виходило з часу.

У моєму випадку браузер робив запит на зворотний проксі-сайт, де я встановив свої правила перенаправлення, і цей проксі-сайт зрештою запитує фактичний сайт. Тепер для величезних даних знадобилося більше 2 хвилин 5 секунд, а час очікування маршрутизації запиту додатків для мого сервера було встановлено на 2 хвилини. Я вирішив це, збільшивши час очікування ARR на наступні кроки: 1. Перейдіть до IIS 2. Клацніть ім'я сервера 3. Клацніть на Запит додатку Кеш маршрутизації на середній панелі 4. Виберіть Налаштування проксі сервера на правій панелі 5. Збільшити час очікування 6 Натисніть Застосувати

У нашому випадку причиною був недійсний заголовок. Як зазначено у редакції 4:

• брати колоди
• у глядачі виберіть Події
• вибрав HTTP2_SESSION

Шукайте щось подібне:

HTTP2_SESSION_RECV_INVALID_HEADER

-> error = "Недійсний символ у назві заголовка."

-> header_name = " charset = utf-8 "

Моя команда побачила це в одному файлі javascript, який ми обслуговували. Кожен інший файл працював чудово. Ми переключились зі http2спини на, http1.1а потім net::ERR_INCOMPLETE_CHUNKED_ENCODINGабо ERR_CONTENT_LENGTH_MISMATCH. Зрештою, ми виявили, що існував корпоративний фільтр (Trustwave), який помилково виявляв "інформаційний випуск" (ми підозрюємо, що він виявив щось у нашому файлі / імені файлу, що нагадувало номер соціального страхування). Отримавши корпоративне налаштування цього фільтра, ми вирішили наші проблеми.

Ми зіткнулися з цією проблемою на сторінках із довгими рядками Base64. Проблема виникає через те, що ми використовуємо CloudFlare.

Детальніше: https://community.cloudflare.com/t/err-http2-protocol-error/119619 .

Основний розділ у форумі:

Після подальшого тестування на вкладках Incognito в декількох браузерах, після чого зміни коду від BASE64 до реального .png зображення, проблема жодного разу не повторювалася в будь-якому браузері. Перш ніж стати base64, у .png було близько 500 кбіт, тому у CloudFlare виникають проблеми з величезними рядками тексту на тому ж рядку (оскільки base64 - це довгий рядок) як проксі між доменом та heroku. Як згадувалося раніше, безпосередньо потрапляючи на URL-адресу Heroku, жодного разу не траплялося цього питання.

Тимчасовий хак - це відключити HTTP / 2 на CloudFlare.

Сподіваємось, що хтось інший може створити краще рішення, яке не потребує відключення HTTP / 2 на CloudFlare.