400 Bad Request: Ne Anlama Gelir, Nasıl Düzeltilir

400 Bad Request ne anlama gelir

RFC 9110, 400'ü sunucunun isteğin bozuk sözdizimi nedeniyle anlaşılamadığını söyleme yolu olarak tanımlar. Anahtar kelime sözdizimidir: sunucu kim olduğunuzu, neyi yapmaya yetkili olduğunuzu veya kaynağın var olup olmadığını değerlendirmiyor. İsteğin kendisinin, telden geçen baytlar olarak, geçerli bir HTTP isteği olarak ayrıştırılamadığını söylüyor. Bu, ayrıştırıcının nerede vazgeçtiğine bağlı olarak istek satırı, başlıklar veya gövde olabilir.

Hata nasıl görünür

Tarayıcılar, sunucunun bir 400 için geri gönderdiği düz hata sayfasını gösterir; bir DNS veya sertifika hatasında olduğu gibi özel bir tarayıcı düzeyinde sayfa yoktur, çünkü bağlantı başarılı oldu ve bir yanıt geldi. Yaygın bir varyant tam olarak "400 Bad Request - request header or cookie too large" okur, ki bu nedeni doğrudan belirtir. Komut satırından:

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Sunucu günlükleri burada en yararlı kanıttır, çünkü bir TLS el sıkışma hatasının aksine, istek uygulama katmanına gerçekten ulaşır ve genellikle ayrıştırılamayan belirli başlık veya satırla birlikte günlüğe kaydedilir.

400 Bad Request'e ne sebep olur

Bir ziyaretçi için, gerçekten karşılaşma olasılığınızın en yüksek olduğu sırayla:

• Aşırı büyük veya bozuk çerezler. Bir alan adı için yıllar içinde biriken çerezler, veya bir uzantı ya da kötü bir yönlendirme tarafından bozulmuş bir çerez, toplam başlık boyutu sunucunun sınırını aştığında rutin olarak tam olarak "400 Bad Request - request header or cookie too large" mesajını üretir.
• Yanlış yazılmış veya kötü kodlanmış bir URL. Adres çubuğunda veya yapıştırılmış bir bağlantıda başıboş bir karakter, kodlanmamış bir boşluk veya bozuk bir yüzde kodlama dizisi, geçerli sözdizimi olarak ayrıştırılamayabilir.
• İstekleri değiştiren bir tarayıcı uzantısı. Reklam engelleyiciler, gizlilik araçları ve bazı VPN uzantıları başlıkları veya istek satırını yeniden yazar, ve bunlardan birindeki bir hata sunucuya bozuk bir şey verebilir.
• Bozuk bir URL'ye işaret eden önbelleğe alınmış bir yönlendirme. Tarayıcı, kendisi geçersiz olan bir URL'ye eski bir yönlendirmeyi takip eder, ve 400 gerçekte tıkladığınız bağlantıda değil hedefte ortaya çıkar.
• Sunucunun izin verdiğinden daha büyük bir dosya yükleme. Bazı sunucu yapılandırmaları, aşırı büyük bir yüklemeye daha spesifik olan 413 Payload Too Large yerine 400 ile yanıt verir.

Site sahibi için, kabaca önce kontrol edilmeye değer sırayla:

• Uygulamanın gerçekte gönderdiğine göre çok düşük ayarlanmış başlık veya çerez boyutu sınırları, özellikle izleme çerezleri, başlıklardaki JWT'ler veya zamanla büyüyen bir oturum mekanizması eklendikten sonra.
• Geçersiz veya eksik bir Host başlığı, ki bunu bir ters proxy veya yanlış yapılandırılmış bir istemci üretebilir, ve çoğu sunucu isteği yönlendirmek için buna ihtiyaç duyar.
• Gerçekte gönderilen gövdeyle eşleşmeyen bir Content-Length, ki bunu bozuk bir istemci veya aradaki hatalı bir proxy neden olabilir.
• Web uygulama güvenlik duvarı veya ModSecurity kuralları, bir insana sözdizimi olarak iyi görünen ama WAF'ın bozuk olarak ele aldığı savunmacı bir kalıba uyan bir isteği reddediyor.
• Bir API'nin bozuk JSON'u kasıtlı olarak 400 ile reddetmesi. Bu doğru davranıştır, bir hata değil: geçerli JSON olarak ayrıştırılamayan bir istek gövdesi, veya API'nin sözdizimi düzeyinde doğruladığı gerekli bir alanı eksik olan bir istek, tasarım gereği 400 döndürmelidir.

Kimin hatası olduğunu nasıl anlarsınız

Aynı isteği temiz bir ortamdan yeniden üretin: uzantısı ve birikmiş çerezi olmayan bir gizli tarama penceresi, veya aynı URL'ye düz bir curl çağrısı. Temiz istek başarılı olursa, neden yereldi, çoğunlukla çerezler veya bir uzantı. Temiz bir istemciden ve tamamen başka bir yerden aynı şekilde başarısız olursa, sunucunun kendi sınırları veya kuralları meşru olarak oluşturulmuş bir isteği reddediyordur, ve bunu ölçekte doğrulamanın en hızlı yolu birkaç konumdan aynı anda bir HTTP kontrolü çalıştırmak ve her birinin geri aldığı durum kodunu karşılaştırmaktır.

400 Bad Request nasıl düzeltilir

Bir ziyaretçiyseniz

1. Önce site için çerezleri temizleyin, çünkü aşırı büyük veya bozuk çerezler açık ara en yaygın nedendir. Çoğu tarayıcı, diğer tüm oturumları silmeden tek bir site için çerezleri temizlemenize izin verir.
2. Gizli veya gizli tarama penceresinde yeniden deneyin. Temiz bir pencerede biriken çerez yoktur ve tarayıcıya bağlı olarak varsayılan olarak çoğu uzantıyı devre dışı bırakır, ki bu her iki yaygın nedeni de aynı anda izole eder.
3. URL'yi yazım hataları veya başıboş karakterler için kontrol edin, özellikle izleme parametreleri eklemiş veya kodlamayı bozmuş olabilecek bir yerden bağlantı yapıştırdıktan sonra.
4. Hata normal bir pencerede devam ediyor ama gizli taramada devam etmiyorsa uzantıları birer birer devre dışı bırakın, hangisinin isteği yeniden yazdığını bulmak için.
5. Farklı bir cihaz veya ağ deneyin siteyle hiç ilgisi olmayan bir yakalama portalı veya yerel bir proxy'yi elemek için.

Siteyi çalıştırıyorsanız

1. Uygulama gerçekten daha büyük olmalarına ihtiyaç duyuyorsa başlık ve tampon sınırlarını yükseltin. nginx'te:

   large_client_header_buffers 4 16k;

   Apache'de:

   LimitRequestFieldSize 16384

   IIS'te, istek gövdesi için web.config içindeki maxRequestLength'ı ve tek tek başlık alanları için HTTP.sys MaxFieldLength kayıt defteri ayarını her ikisini de kontrol edin.
2. Sadece tavanı yükseltmek yerine çerezlerde ve başlıklarda gerçekte gönderdiğinizi azaltın. Eski çerezleri budamak, büyük token'ları başlıklardan çıkarmak ve daha kısa çerez ömürleri ayarlamak, kullanım büyüdükçe sorunun yeniden ortaya çıkmasını önler.
3. Ters proxy'de veya yük dengeleyicide Host başlığı işlemesini kontrol edin, ve uygulamaya geçerli, beklenen bir değer ilettiğini doğrulayın.
4. Uygulamanın önünde bir WAF varsa, tetiklenen belirli kural için WAF veya ModSecurity günlüklerini okuyun; orada yanlış pozitif, devre dışı bırakılmış bir kural setine değil, kapsamlı bir istisnaya ihtiyaç duyar.
5. "Düzeltmeden" önce API'nizden gelen 400'ün kasıtlı olduğunu doğrulayın. Sözdizimi düzeyinde doğrulamayı geçemeyen bozuk bir JSON gövdesi veya bir alan 400 döndürmelidir; bu durumda düzeltme durum kodunu değiştirmek değil, daha net istemci tarafı hata mesajlarıdır.

400'e karşı benzer kodlar

• 401 Unauthorized isteğin gayet iyi anlaşıldığı ama geçerli kimlik bilgilerinin eksik olduğu veya reddedildiği anlamına gelir.
• 403 Forbidden isteğin gayet iyi anlaşıldığı ama sunucunun kimlik bilgilerine bakmaksızın yetkilendirmeyi reddettiği anlamına gelir.
• 404 Not Found isteğin gayet iyi anlaşıldığı ve yola hiçbir kaynağın eşleşmediği anlamına gelir.
• 413 Payload Too Large, bir boyut sınırını aşan bir gövde için özel koddur, ancak bazı sunucular pratikte bunun yerine 400 ile yanıt verir.
• 414 URI Too Long, bir uzunluk sınırını aşan bir istek satırı için özel koddur.
• 422 Unprocessable Content, sözdiziminin gayet iyi ayrıştırıldığı ama anlamının ayrıştırılmadığı anlamına gelir, örneğin iş doğrulamasını geçemeyen bir değere sahip geçerli JSON, ki bu çoğu API'nin 400'den ayırt etmeye zahmet ettiğinden daha ince bir ayrımdır.

Bir 400 hatasının bir sayfayı çökertmesi nasıl önlenir

Başlık sınırlarını sıkılaştıran bir dağıtım veya meşru trafiği eşleştirmeye başlayan bir WAF kural güncellemesi tarafından tanıtılan bir 400, bir çökme veya zaman aşımı olarak görünmeyecektir, çünkü sunucu kendi kurallarına göre anında ve doğru şekilde yanıt verir. Beklenen durum kodu üzerinde bir doğrulaması olan zamanlanmış bir HTTP kontrolü, destek biletleri yığılmasını beklemek yerine, bunu başladığı anda yakalar. Birden fazla konumdan izleme ile birleştirildiğinde, 400'ün evrensel mi yoksa bir bölgenin kenar yapılandırmasına bağlı mı olduğunu da size söyler.

İlgili hatalar

Daha geniş istemci ve sunucu hata kodları ailesi 4xx durum kodu genel bakışında ele alınır. Sunucunun anladığı ve reddettiği istekler için ayrıca 403 Forbidden'a, var olmayan bir kaynağı hedefleyen istekler için 404 Not Found'a ve sözdizimi yerine oran nedeniyle reddedilen istekler için 429 Too Many Requests'e bakın.

Sık sorulan sorular

Çerezleri temizlemek neden bir 400 hatasını düzeltir?

Çünkü çerezler her istekte istek başlıkları olarak gider, ve bir sunucu maksimum toplam başlık boyutunu zorunlu kılar. Yıllarca biriken çerezler, veya tek bir bozuk çerez, toplamı bu sınırın ötesine itebilir, ve sunucu istek hakkında başka bir şey okumadan önce 400 ile yanıt verir.

400 hatası ziyaret ettiğim her web sitesinde aynı mı?

Kod ve genel neden, bozuk istek sözdizimi, her yerde aynıdır, ama aşılan tam sınır ve hata sayfasının tam ifadesi her sitenin kendi sunucu yapılandırması tarafından belirlenir.

API'm geçersiz girdi için 400 döndürmeli mi?

Evet, girdi ayrıştırılamadığında veya API'nin sözdizimi düzeyinde kontrol ettiği bir alan eksik olduğunda. Bu, doğrulamayı gevşeterek düzeltilecek bir hata değil, tasarlandığı gibi çalışan 400'dür.

Bir WAF, tamamen normal görünen bir istekte 400 hatasına neden olabilir mi?

Evet. Bir WAF kuralı, teknik olarak geçerli HTTP olan ama savunmacı bir imzaya uyan bir URL, başlık veya gövdedeki bir kalıbı işaretleyebilir, ve bazı WAF yapılandırmaları daha spesifik bir engelleme sayfası yerine genel bir 400 ile yanıt verir.

400 ile 413 arasındaki fark nedir?

413, yapılandırılmış bir boyut sınırını aşan bir istek gövdesi için özel koddur. Birçok sunucu bunu doğru kullanır, ama bazıları aynı aşırı büyük gövde koşulu için bunun yerine 400 ile yanıt verir, bu yüzden sunucunun kendi belgelerini veya günlüklerini kontrol etmeden yalnızca kodun size tam nedeni söylediğini varsaymayın.