406 Not Acceptable: Ne Anlama Gelir, Nasıl Düzeltilir

406 Not Acceptable ne anlama gelir

HTTP, bir Accept başlıkları ailesi aracılığıyla içerik müzakeresini destekler: yanıtın medya türü için Accept, dil için Accept-Language, ve sıkıştırma için Accept-Encoding. Bir istemci "sadece kullanabileceğim bir yanıt ver" demek için bunlardan herhangi birini gönderebilir. RFC 9110'a göre, sunucu istemcinin kabul edeceğini belirttiği bir temsili üretemiyorsa, ve bunu yine de bir şey göndermek yerine bunu sinyallemeyi seçerse, 406 ile yanıt verir. Pratikte, çoğu sunucu dar bir Accept başlığını sessizce görmezden gelir ve bunun yerine varsayılan yanıtını gönderir, ki bu yüzden gerçek bir 406, başlığın kendisinden daha az yaygındır.

Hata nasıl görünür

Bir tarayıcı, normal sayfa yüklemelerinde nadiren bir 406 tetikler, çünkü tarayıcılar bir sunucunun sunduğu neredeyse her şeyle eşleşen izin verici Accept başlıkları gönderir. Katı bir Accept başlığı ayarlayan API istemcilerinden, betiklerden ve komut satırı araçlarından çok daha sık görünür:

curl -i -H "Accept: application/xml" https://api.example.com/v1/status
HTTP/1.1 406 Not Acceptable
Content-Type: application/json

Bu örnekte istemci sadece XML istedi ve API sadece JSON üretebilir, bu yüzden sunucu istemcinin açıkça istemediğini söylediği bir biçim göndermek yerine reddediyor.

406 Not Acceptable'a ne sebep olur

• İçerik müzakeresinin gerçekten başarısız olması. Sadece sunucunun üretemediği biçimleri adlandıran bir Accept, Accept-Language, veya Accept-Encoding başlığı, çoğunlukla bir JSON-only API'den XML isteyen bir istemci, veya sunucunun sahip olmadığı belirli bir dil varyantı.
• Paylaşımlı barındırmada bir web uygulama güvenlik duvarı. Bu, içerik müzakeresiyle hiçbir ilgisi olmayan çok yaygın gerçek dünya nedenidir: paylaşımlı barındırma ortamlarındaki ModSecurity ve benzer WAF kuralları, Accept başlığı alışılmadık, eksik veya otomatik görünen istekleri engeller ve müzakere edilen şeye bakılmaksızın engelleme yanıtı olarak 406 ile yanıt verir.
• Sadece JSON sunan, Accept: text/html gönderen bir istemciye çarpan bir API. Bazı API'ler bu konuda katıdır ve düşürmek yerine reddeder, ki bu doğrudan uç noktada açılmış bir tarayıcı sekmesi dahil herhangi bir istemci için 406 olarak yüzeye çıkar.
• Önbellekleme veya bot filtreleme nedenleriyle Accept başlığına dayanarak inceleyen ve reddeden yanlış yapılandırılmış bir ters proxy veya CDN kuralı, kaynak sunucunun üretebildiğiyle ilgisiz.
• Aşırı katı Accept-Encoding işleme. Sıkıştırılmamış bir yanıta geri dönmek yerine, tercih ettiği bir sıkıştırma yöntemini listelemeyen herhangi bir isteği reddedecek şekilde yapılandırılmış bir sunucu.

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

Belirli bir betik veya entegrasyon 406'ya çarpan tek şeyse, Accept başlıklarının ne dediğini kontrol edin, çünkü istemci tarafında daraltılmış veya yanlış yapılandırılmış bir başlık genellikle doğrudan nedendir. Aynı istek düz, izin verici bir Accept başlığıyla çalışıyor ama belirli biriyle başarısız oluyorsa, sunucu o biçimi gerçekten sunamıyor. Normal tarayıcı trafiği de etkileniyorsa, veya hata sizin tarafınızda hiçbir kod değişikliği olmadan bir barındırma veya WAF değişikliğinden hemen sonra başladıysa, paylaşımlı barındırma güvenlik kuralları daha olası suçludur, ve entegrasyonunuzun gönderdiği tam başlıklarla birden fazla konumdan bir HTTP kontrolü çalıştırmak, engelin tutarlı mı yoksa bir ağa mı özgü olduğunu doğrulamanın en hızlı yoludur.

406 Not Acceptable nasıl düzeltilir

Bir ziyaretçiyseniz

1. Kontrol ettiğiniz herhangi bir betik veya araçta Accept başlığını kaldırın veya gevşetin, ve sunucunun sunduğu varsayılan biçimi kabul etmesine izin verin.
2. Sunucunun bozuk olduğunu varsaymadan önce hangi içerik türlerini ve dillerini desteklediği için API'nin belgelerini kontrol edin.
3. İsteği doğrudan bir tarayıcıdan deneyin, çünkü tarayıcılar geniş Accept başlıkları gönderir ve bu hataya nadiren çarpar, ki bu engelin istemcinizin başlıklarına özgü olduğunu doğrulamaya yardımcı olur.

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

1. 406 beklenmedikse ve yaygınsa önce ModSecurity veya WAF kurallarınızı kontrol edin, çünkü paylaşımlı barındırma ortamları sıklıkla gerçek bir müzakere başarısızlığı yerine Accept başlığı kalıpları üzerinde engeller. Uygulama koduna dokunmadan önce eşleşen kural kimliği için WAF'ın kendi günlüklerine bakın.
2. API'nizin gerçekte hangi biçimleri sunduğunu doğrulayın, ve ya gerçek istemcilerin istediklerinin daha fazlasını destekleyin ya da gereksinimi açıkça belgeleyin, böylece bir 406 şaşırtıcı değil bilgilendirici olur.
3. API'niz için kabul edilebilir olduğunda, doğrudan reddetmek yerine varsayılan bir temsile geri dönün, çünkü çoğu gerçek dünya istemcisi tamamen bir reddiyeden "işte geniş bir şekilde istediğinize rağmen JSON" konusunu daha iyi işler.
4. Önbellekleme veya bot yönetimi için Accept başlığını inceleyen herhangi bir şey için ters proxy ve CDN kurallarını kontrol edin, çünkü bir amaç için tasarlanmış bir kural, ilgisiz trafik için yan etki olarak 406 üretebilir.

Bir entegrasyonu çökerten bir 406 nasıl önlenir

Bir barındırma sağlayıcısının güvenlik güncellemesi veya yeni bir WAF kuralı tarafından tanıtılan bir 406, kendi ağınızın içinden bir kesinti gibi görünmeyecektir, çünkü kendi istekleriniz etkilenen bir entegrasyondan farklı başlıklar kullanabilir. Gerçek istemcilerinizin kullandığı aynı Accept başlığını gönderen, beklenen durum kodu üzerinde bir doğrulaması olan zamanlanmış bir HTTP kontrolü, bir müzakere başarısızlığını başladığı anda yakalar. Birden fazla konumdan kontrol etmek, aynı zamanda barındırma genelindeki bir WAF kuralını sadece belirli kenar düğümlerinde geçerli olan bir kuraldan ayırmaya yardımcı olur.

İlgili hatalar

İçerik müzakeresi yerine bir isteği tamamen doğrudan engelleyen bir WAF veya bot kuralının yakından ilgili durumu için 403 Forbidden'a, daha geniş aile için 4xx genel bakışına, ve bu partide başka yerde 413 Payload Too Large'a bakın.

Sık sorulan sorular

406 bir CORS hatasıyla aynı mı?

Hayır. CORS başarısızlıkları, tarayıcının çağıran betiğe bir çapraz kaynak yanıtı göstermeyi reddettiği için olur; 406, sunucunun kendisinin istenen biçimi, dili veya kodlamayı karşılayamayacağı için hiç bir yanıt gövdesi üretmeyi reddetmesidir.

406'yı neden sadece curl veya Postman'den görüyorum, tarayıcıdan asla değil?

Tarayıcılar varsayılan olarak geniş, izin verici Accept başlıkları gönderir. curl gibi araçlar siz açıkça bir tane ayarlamadıkça hiçbir şey veya dar bir başlık göndermez, ki bu gerçek bir müzakere başarısızlığını tetikleme veya alışılmadık başlıkları işaretlemek üzere ayarlanmış bir WAF kuralına takılma olasılığı çok daha yüksektir.

Accept başlığım tamamen normal olsa bile ModSecurity'den bir 406 gelebilir mi?

Evet. Birçok paylaşımlı barındırma ModSecurity kural seti, Accept başlıklarının tam yapısı ve sırası dahil bir dizi sinyal kombinasyonuna dayanarak istekleri otomatik olarak işaretler, ve içerik müzakeresi gerçekten başarısız olduğu için değil, genel bir engelleme yanıtı olarak 406 ile yanıt verir.

API'm 406 mı döndürmeli yoksa sadece JSON'a mı varsaymalı?

Makul bir biçime varsaymak gerçek dünya istemcileri için daha dostçadır ve çoğu üretim API'sinin yaptığı şeydir. Yanlış biçimi sessizce sunmak çağırana aktif olarak yanıltıcı olacaksa 406 döndürmek savunulabilir.

406 ile 415 arasındaki fark nedir?

406, istemcinin yanıtta neyi kabul edebileceği hakkındadır. 415 Unsupported Media Type, istemcinin gönderdiği istek gövdesinde sunucunun neyi kabul edebileceği hakkındadır. Aynı müzakere fikrinin zıt yönlerini kapsarlar.