Net :: ERR_HTTP2_PROTOCOL_ERROR ne hakkında?

Şu anda net::ERR_HTTP2_PROTOCOL_ERROR 200Google Chrome'da bir hataya neden olan bir web sitesi üzerinde çalışıyorum . Tam olarak bu hatayı neyin provoke edebileceğinden emin değilim, sadece HTTPS'deki web sitesine erişirken ortaya çıktığını fark ettim. % 100 ilgili olduğundan emin olamıyorum, ancak javascript düzgün yürütülmesini engelliyor gibi görünüyor.

Örneğin, aşağıdaki senaryo gerçekleşir:

1. Web sitesine HTTPS'den erişiyorum

2. Https://publish.twitter.com üzerinden entegre edilen Twitter feed'im hiç yüklenmedi

3. Konsolda ERR_HTTP2_PROTOCOL_ERROR fark edebilirim

4. Twitter özet akışını yüklemek için kodu kaldırırsam hata kalır

5. Web sitesine HTTP ile erişirsem Twitter yayını görünür ve hata kaybolur

Google Chrome, hatayı tetikleyen tek web tarayıcısıdır: Hem Edge hem de Firefox'ta iyi çalışır. (Not: Safari ile denedim ve benzer bir kcferrordomaincfnetwork 303hata var)

Hatada bu '200' sözü olduğundan ve 404/500 sayfasının hiçbir şey tetiklemediğinden sunucu tarafından döndürülen başlık ile ilgili olup olmadığını merak ediyordum.

Şey, hata hiç belgelenmedi. Google arama bana çok az sonuç veriyor. Dahası, çok yeni Google Chrome sürümlerinde göründüğünü fark ettim; hata v.64.X üzerinde açılmaz, ancak v.75 + (OS ne olursa olsun; Mac tho üzerinde çalışıyorum).

Bu noktada araştırılacak herhangi bir ipucu memnuniyetle takdir edilecektir!

Şimdiden teşekkürler.

Tristan

Düzenleme 1: Firefox'ta Web Sitesi Tamam ile ilişkili olabilir, ancak Safari'de olmayabilir (kCFErrorDomainCFNetwork hatası 303) hiçbir Chrome'da (net :: ERR_SPDY_PROTOCOL_ERROR)

Edit 2: Diğer araştırmalardan elde edilen bulgular şunlardır:

• 2XX yerine 404 döndürürse aynı sayfada hata oluşmaz
• hatası HTTPS sertifikasıyla yerel olarak açılmıyor
• Farklı bir sertifika kullanan farklı bir sunucuda hata (her ikisi de OVH'ler)
• PHP sürümü ne olursa olsun hata ortaya çıkar (5.6'dan 7.3'e

Düzenleme 3: İstendiği gibi, tüm web sayfası olan başarısız kaynak için döndürülen başlık aşağıdadır. Hata, HTTP başlığına (200) sahip her sayfada tetiklense bile, bu sayfalar her zaman istemcinin tarayıcısına yüklenir, ancak bazen bir öğe eksiktir (örnekte harici Twitter özet akışı). Ağ sekmesindeki diğer tüm öğelerin, belgenin kendisi hariç bir başarı getirisi vardır.

Google Chrome başlığı (hatalı):

Firefox üstbilgisi (hatasız):

curl --head --http2Konsoldaki bir istek aşağıdaki başarıyı döndürür:

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

Düzenleme 4: chrome: // net-export / ve https://netlog-viewer.appspot.com araçlarıyla daha derine inmeye çalışmak, isteğin bir RST_STREAM ile sona erdiğini söylüyor:

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

Ben okuduklarım için bu diğer yazı ", istemci isteğini iptal etmek istiyorsa, HTTP / 2'de, bir RST_STREAM gönderir. Sunucu bir RST_STREAM aldığında, böylelikle yanıtını durdurarak müşteriye VERİ çerçeveleri göndermeyi durduracak (veya indirme) Bağlantı hala diğer istekler için kullanılabilir ve iptal edilen istekle aynı anda gerçekleşen istekler / yanıtlar ilerlemeye devam edebilir. [...] RST_STREAM'ın istemciyi sunucuya gönderirse, isteğin tüm içeriği aktarılır ve istemciye ulaşır, bu da onu atar.Ancak, büyük yanıt içerikleri için, bir RST_STREAM göndermenin sunucuya bütünden önce gelmesi için iyi bir şansı olabilir yanıt içeriği gönderilir ve bu nedenle bant genişliği tasarrufu sağlanır. "

Açıklanan davranış gözlemleyebildiğim davranışla aynı. Ancak bu, tarayıcının suçlu olduğu anlamına gelir ve sonra neden biri aynı 200 başlık ve diğeri 404 (JS'yi devre dışı bırakırsam aynı şey olur) ile iki özdeş sayfada gerçekleştiğini anlamıyorum.

Birkaç hafta boyunca ben de bu "hata" rahatsız oldu:

net :: ERR_HTTP2_PROTOCOL_ERROR 200

Benim durumumda, PHP tarafından oluşturulan görüntülerde meydana geldi.

Seviyeydi header()ve bu konuda özellikle:

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

Açıkçası tam boyutu döndürmedi, bu yüzden sildim ve şimdi her şey iyi çalışıyor.

Bu nedenle Chrome, üstbilgiler aracılığıyla iletilen verilerin doğruluğunu kontrol eder ve karşılık gelmezse başarısız olur.

DÜZENLE

Neden content-lengthüzerinden filesizeyanlış hesaplandı bulundu : GZIPsıkıştırma PHP dosyaları üzerinde etkin, bu yüzden söz konusu dosyayı hariç sorunu çözecektir. Bu kodu şuraya yerleştirin .htaccess:

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

Çalışır ve başlığı tutarız Content-length.

Tam olarak ne olduğunu anlayamadım, ama bir çözüm buldum.

OVH ait CDN özelliği suçlu oldu. Ana bilgisayar hizmetime yükledim, ancak ihtiyacım olmadığı için alanım için devre dışı bıraktım.

Her nasılsa, onu etkinleştirdiğimde, her şey işe yarıyor.

Apache'yi HTTP2 protokolünü kullanmaya zorladığını düşünüyorum, ancak anlamadığım şey, her bir başlığımda bir HTTP2 sözü olduğu, bu da sunucunun doğru protokolü kullanarak cevap verdiği anlamına geldiğini düşünüyorum.

Bu yüzden benim çok özel durumum için çözüm, ilgili tüm alanlarda CDN seçeneğini etkinleştirmekti.

Burada ne olabileceğini daha iyi anlarsanız, açıklamaları paylaşmaktan çekinmeyin.

Http2 sunucusu Chrome'a ​​büyük bir yanıt gönderirken bağlantıyı kapattığı için bununla karşılaştım .

Neden? Çünkü bu yalnızca http2 sunucusunun WriteTimeout adlı bir ayarıdır .

Benim durumumda - web sunucusunda disk alanı kalmadı.

Benzer bir sorunla karşılaştım, HTTP GET isteklerinden birinde ERR_HTTP2_PROTOCOL_ERROR alıyordum.

Chrome güncellemesinin beklemede olduğunu fark ettim, bu yüzden Chrome tarayıcıyı en son sürüme güncelledim ve tarayıcıyı tekrar başlattığımda hata gitti.

Düğüm-js uygulama dış dünyaya maruz bir Nginx sunucusu yaparken bu sorun vardı. Nginx dosyayı (css, js, ...) sıkıştırılmış hale gzipgetirdi ve Chrome ile aynı görünüyordu.

Düğüm-js sunucusunun içeriği gzip ile sıkıştırdığını tespit ettiğimizde sorun çözüldü. Bir şekilde, bu çift sıkıştırma bu soruna yol açar. Düğüm-js sıkıştırmasını iptal etmek sorunu çözdü.

Bu hata şu anda düzeltiliyor: https://chromium-review.googlesource.com/c/chromium/src/+/2001234

Ama nginx ayarlarını değiştirerek bana yardımcı oldu:

• gzip'i açma;
• add_header 'Cache-Control' 'mağaza yok, önbellek yok, yeniden doğrulamalı, proxy yeniden doğrulamalı, maks. yaş = 0';
• süresi doluyor;

Benim durumumda, Nginx Node.js uygulaması için ters proxy olarak işlev görür.

Yeni bir alan adı kaydettirdiğimde bu oldu, örneğin ornek.com (new.example.com) için "new". Ad, bulunduğum yerde geçici olarak birkaç saat boyunca çözülemedi, ancak yurtdışında çözülebildi. Bu yüzden net::ERR_HTTP2_PROTOCOL_ERRORbazı AJAX gönderileri için krom konsolunda gördüğüm web sitesini test etmek için bir proxy kullandım . Saatler sonra, ad yerel olarak yeniden çözülebildiğinde, bu hata ortadan kayboldu.

Bu hatanın nedeni, AJAX isteklerinin proxy'im tarafından yönlendirilmediğini düşünüyorum, sadece yerel DNS çözümleyici tarafından çözülmemiş bir web sitesini ziyaret ediyor.

Birkaç kez bu hatayla karşılaştım ve bunun nedeni büyük kaynakların (3MB'den büyük) sunucudan istemciye aktarılmasıydı.

(Uygulama dosya boyutu için herhangi bir sınırlama olmamasına rağmen) 1MB daha büyük bir dosya gönderirken aynı sorunu (asp, c # - HttpPostedFileBase) aldım, benim için model sınıfının basitleştirilmesi yardımcı oldu. Bu sorunu yaşarsanız, modelin bazı bölümlerini kaldırmayı deneyin ve herhangi bir şekilde yardımcı olup olmayacağını görün. Kulağa tuhaf geliyor, ama benim için çalıştı.

AJAX aracılığıyla PHP sunucuma DELETE istekleri göndermeye çalışıyorum gibi ben geçen hafta bu sorun yaşıyorum. Kısa bir süre önce, PHP ve JS dosyalarını barındıran sunucumda SSL Sertifikası bulunan barındırma planımı yükselttim. SSL Sertifikası eklediğimden beri artık bu sorunla karşılaşmıyorum. Bunu ummak, bu garip hataya yardımcı olur.

Bu hatayla da karşılaştım ve bunun arkasında birden fazla neden olabileceğine inanıyorum. Benimki ARR zaman aşımına uğradı.

Benim durumumda, tarayıcı, yönlendirme kurallarımı ayarladığım ve proxy sitesinin sonunda gerçek siteyi talep ettiği bir ters proxy sitesine bir istekte bulunuyordu. Şimdi devasa veriler için 2 dakika 5 saniyeden fazla sürüyordu ve sunucum için Uygulama İsteği Yönlendirme zaman aşımı 2 dakikaya ayarlanmıştı. Aşağıdaki adımları izleyerek ARR zaman aşımını artırarak sorunu çözdüm: 1. IIS'ye gidin 2. Sunucu adına tıklayın 3. Orta bölmedeki Uygulama İsteği Yönlendirme Önbelleği'ne tıklayın 4. Sağ bölmedeki Sunucu Proxy ayarları'na tıklayın 5. Zaman aşımını artırın 6 Uygula'yı tıklayın.

Bizim durumumuzda, neden geçersiz başlıktı. Düzenleme 4'te belirtildiği gibi:

• kütükleri al
• görüntüleyicide Etkinlikler'i seçin
• HTTP2_SESSION seçti

Benzer bir şey arayın:

HTTP2_SESSION_RECV_INVALID_HEADER

-> error = "Başlık adında geçersiz karakter."

-> header_name = " karakter kümesi = utf-8 "

Ekibim bunu hizmet verdiğimiz tek bir javascript dosyasında gördü. Diğer her dosya iyi çalıştı. Biz http2arkadan http1.1ve sonra ya net::ERR_INCOMPLETE_CHUNKED_ENCODINGya geçti ERR_CONTENT_LENGTH_MISMATCH. Sonuçta hatalı bir şekilde "geçersiz" tespit eden bir şirket filtresi (Trustwave) olduğunu keşfettik (dosya / dosya adımızda bir sosyal güvenlik numarasına benzeyen bir şey tespit ettiğinden şüpheleniyoruz). Bu filtreyi düzeltmek için kurumsal olmak sorunlarımızı çözdü.

Bu sorunu uzun Base64 dizeleri olan sayfalarda yaşadık. Sorun, CloudFlare kullandığımız için oluşur.

Ayrıntılar: https://community.cloudflare.com/t/err-http2-protocol-error/119619 .

Forum gönderisinden anahtar bölüm:

Birden çok tarayıcıda Gizli sekmeler üzerinde daha fazla test yaptıktan sonra koddaki değişiklikleri bir BASE64'ten gerçek bir .png görüntüsüne yaptıktan sonra, sorun HERHANGİ BİR tarayıcıda bir daha olmadı. .Png, base64 olmadan önce yaklaşık 500 kb'ye sahipti, bu nedenle CloudFlare, alan ve heroku arasında bir proxy olarak aynı satırda büyük metin satırlarıyla (base64 uzun bir dize olduğundan) sorunlar yaşıyor. Daha önce de belirtildiği gibi, Heroku url'ye doğrudan vurmak da sorun olmadı.

Geçici saldırı, CloudFlare üzerinde HTTP / 2'yi devre dışı bırakmaktır.

Başka birinin CloudFlare'da HTTP / 2'yi devre dışı bırakmayı gerektirmeyen daha iyi bir çözüm üretebileceğini umuyoruz.