405 Method Not Allowed: Nedenleri ve Çözümleri

405 Method Not Allowed ne anlama gelir

RFC 9110, bir 405 yanıtının kaynağın gerçekte desteklediği yöntemleri listeleyen bir Allow başlığı içermesini gerektirir. O başlık tek bir satırda tüm teşhistir: /api/users'a bir istek Allow: GET, HEAD ile 405 döndürüyorsa, rota var ve okuma için gayet iyi çalışıyor, sadece gönderdiğiniz yöntem için hiç bir işleyici bağlanmamış.

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

Hata nasıl görünür

Tarayıcılar, normal bir gezinmeye döndürülen bir 405 için genel bir hata sayfası gösterir, çünkü bu onların özel işleme yaptığı bir durum değildir. Çoğu 405, tıklanan bağlantılardan çok betiklenmiş isteklerden geldiğinden, bir ağ sekmesinde, başarısız bir AJAX çağrısında, veya konsolda bir CORS ön uçuş başarısızlığında karşılaşmak çok daha yaygındır. Komut satırından, yöntem ve Allow başlığı tüm hikayeyi anlatır:

curl -i -X POST https://example.com/downloads/report.pdf
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

405 Method Not Allowed'a ne sebep olur

• Statik bir dosyaya POST etmek. Sadece statik içerik için GET ve HEAD'e yanıt veren bir web sunucusu tarafından sunulan, bir PDF veya resim gibi diskteki gerçek bir dosya için istek.
• Sadece bazı yöntemleri tanımlayan bir rotayı çağırmak. Sadece GET için kayıtlı bir çatı rotası, tasarım gereği, 404 yerine diğer her fiil için 405 döndürür.
• Reddedilen bir CORS ön uçuş OPTIONS isteği. Tarayıcılar, belirli çapraz kaynak çağrılardan önce otomatik bir OPTIONS isteği gönderir, ve o yolda OPTIONS için hiçbir işleyicisi olmayan bir sunucu veya ağ geçidi 405 ile yanıt verir, ki bu sonra tarayıcıda net bir 405 yerine engellenen bir çapraz kaynak isteği olarak yüzeye çıkar.
• Statik dosyalar için tasarlanmış bir konum bloğu sunan nginx. Dosya sistemine karşı try_files kullanan bir proxy_pass olmadan bir location bloğu, POST'ta 405 verecektir, çünkü nginx'te statik dosya sunumu sadece GET, HEAD, ve varsayılan olarak sınırlı bir yöntem kümesi uygular.
• WebDAV ve IIS fiil kısıtlamaları. IIS ve bazı WebDAV etkin sunucular yol başına fiilleri açıkça beyaz listeye alır, ve o listenin dışındaki bir yöntem, PROPFIND gibi özel olanlar dahil, genel rota aksi takdirde çalışsa bile 405 alır.
• Çatı rotası yanlış yapılandırması. Hem GET hem de POST kabul etmesi amaçlanan ama sadece biri için kayıtlı bir rota, genellikle rota bildirimini güncellemeden bir işleyiciyi bölen bir yeniden düzenlemeden sonra.
• Bir yük dengeleyici veya API ağ geçidi yöntem beyaz listesi. Bazı ağ geçitleri, uygulamadan bağımsız olarak rota başına izin verilen yöntemleri kısıtlar, ve uygulama reddedilen isteği hiç görmez.

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

Tarayıcılar ve normal bağlantılar kendi başlarına keyfi yöntemler göndermediğinden, bir 405 neredeyse her zaman bir ziyaretçinin neden olduğu bir şey yerine sunucu tarafında bir yapılandırma veya kod sorunudur. Bir sayfa çoğunlukla çalışıyor ama bir form gönderimi veya istemci tarafı JavaScript'ten bir API çağrısı gibi tek bir eylem 405 ile başarısız oluyorsa, o belirli isteğin yönteminin uç noktanın beklediğiyle eşleşip eşleşmediğini kontrol edin. Eşleşiyorsa ve hata yeniyse, bir rota veya proxy yapılandırmasının bozulduğunu doğrulamanın en hızlı yolu, uygulamanızın kullandığı tam yöntemi gönderen bir HTTP kontrolü çalıştırmak ve sonucu son bir dağıtım genelinde karşılaştırmaktır.

405 Method Not Allowed nasıl düzeltilir

Bir ziyaretçiyseniz

1. Eylemi yeniden yükleyin ve yeniden deneyin, çünkü bir form gönderiminden gelen bir 405 bazen yanlış uç noktaya işaret eden formun eski önbelleğe alınmış bir sürümünü yükleyen bir sayfayı takip edebilir.
2. Sorun devam ederse site için tarayıcı önbelleğini temizleyin, eski bir service worker veya önbelleğe alınmış bir yanıtın eski, artık uyumsuz bir isteği tekrarladığı ihtimaline karşı.
3. Bunu siteye bildirin, çünkü bu neredeyse her durumda onların tarafında bir yapılandırma sorunudur; yöntemi gerçekten kabul etmeyen bir sunucu için istemci tarafı bir düzeltme yoktur.

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

1. Kendi 405 yanıtınızdaki Allow başlığını okuyun o yol için sunucunun hangi yöntemleri geçerli saydığını tam olarak doğrulamak için, sonra istemcinin gerçekte gönderdiğiyle karşılaştırın.
2. Eksik yöntemi rotaya ekleyin. Çoğu çatıda bu tek satırlık bir rota bildirimidir; hangi fiilin eksik olduğunu bildiğinizde düzeltme nadiren uygulama mantığındadır.
3. CORS etkin rotalar için OPTIONS'ı açıkça işleyin. Ya çatınızın CORS ara katman yazılımının ön uçuş isteklerini otomatik olarak yanıtlamasına izin verin, ya da doğru Allow ve Access-Control-Allow-Methods başlıklarını döndüren bir işleyici ekleyin.
4. Statik bir dosya bloğu bir arka uç gerektiren bir rotayı yakalıyorsa nginx konum bloğunu düzeltin. Onu dosya olarak sunmak yerine POST'u ileten minimal bir örnek:

   location /api/ {
       proxy_pass http://backend;
   }

5. Ağ geçidi ve yük dengeleyici yöntem beyaz listelerini uygulamadan ayrı olarak kontrol edin, çünkü bir istek kodunuza hiç ulaşmadan reddedilebilir, ve uygulama günlükleri onun için hiçbir şey göstermez.

Bir dağıtımdan sonra sessiz bir 405 nasıl önlenir

Bir yeniden düzenleme sırasında bir yöntemi kaybeden bir rota, veya daha önce yapmadığı bir yolu ele geçirmeye başlayan bir proxy kuralı, hiçbir yerde bir istisna fırlatmaz, sadece yanlış ama geçerli bir HTTP yanıtı yanıtlar. Entegrasyonunuzun güvendiği tam yöntemle gönderilen, durum kodu üzerinde bir doğrulaması olan zamanlanmış bir HTTP kontrolü, kullanıcılar bozuk formları bildirmeden önce değil, buna neden olan dağıtımdan hemen sonra o gerilemeyi yakalar. Özellikle API uç noktaları için, hem yöntemi hem de yanıt gövdesini kontrol eden API izlemesi, rotanın sadece isteği kabul etmediğini, hâlâ doğru davrandığını da doğrular.

İlgili hatalar

Yöntemi reddeden ama var olan bir yolun aksine hiç var olmayan bir yol için 404 Not Found'a, tüm aile için 4xx genel bakışına, ve bu partide başka yerde 401 Unauthorized ve 422 Unprocessable Content'e bakın.

Sık sorulan sorular

404 ile 405 arasındaki fark nedir?

404, o yolda herhangi bir yöntem için hiçbir şeyin var olmadığı anlamına gelir. 405, yolun var olduğu ve en az bir yöntem için çalıştığı, sadece kullandığınız için değil, anlamına gelir, ve Allow başlığı hangi yöntemlerin geçerli olduğunu doğrular.

Bir CORS isteği neden 405 gibi görünen bir şeyle başarısız olur?

Tarayıcılar, birçok çapraz kaynak isteğinden önce otomatik bir OPTIONS ön uçuşu gönderir. Sunucunun o rotada OPTIONS için hiçbir işleyicisi yoksa, 405 ile yanıt verir, ve tarayıcı bunu ham durum kodunu doğrudan göstermek yerine konsolda bir CORS başarısızlığı olarak bildirir.

405, bir API'nin kasıtlı olarak göndereceği doğru yanıt olabilir mi?

Evet. Bir kaynak gerçekten sadece okumayı destekliyorsa, ona karşı bir PUT veya DELETE için 405 döndürmek doğru REST davranışıdır, ve çağıran için genel bir 404'ten daha bilgilendiricidir.

Bir güvenlik duvarı veya WAF bir 405'e neden olabilir mi?

Bir uygulama veya proxy yanlış yapılandırmasından daha az yaygındır, ama bazı WAF kural setleri yol başına izin verilen yöntemleri kısıtlar ve istek kaynağa hiç ulaşmadan önce 405 veya benzer bir engelleme yanıtı verir.

Allow başlığı neden bazen hâlâ başarısız olan yöntemleri listeler?

Allow başlığı, rotanın tam olarak ne için uygulandığını değil, ne için kayıtlı olduğunu yansıtır. Bir yöntem, yöntem kontrolünü geçtikten sonra eksik yetkilendirme gibi başka nedenlerle bildirilebilir ve yine de bir hata döndürebilir.