405 Method Not Allowed Hatası: Nedir ve Nasıl Çözülür?

405 Method Not Allowed Hatası Nedir?

405 Method Not Allowed (izin verilmeyen yöntem), sunucunun istediğiniz adresi tanıdığı, ancak isteğinizin kullandığı yönteme izin vermediği anlamına gelen bir HTTP durum kodudur. RFC 9110 (bölüm 15.5.6) bunu, yöntemin "known by the origin server but not supported by the target resource" (kaynak sunucu tarafından bilinen, ancak hedef kaynak tarafından desteklenmeyen) olması şeklinde tanımlar.

Her HTTP isteğinin bir yöntemi vardır: bir sayfayı okumak için GET, bir form göndermek veya bir şey oluşturmak için POST, güncellemek için PUT ve PATCH, silmek için DELETE, nelere izin verildiğini sormak için OPTIONS. 405, URL'nin var olduğu, ancak o fiil için var olmadığı anlamına gelir. URL hiç var olmasaydı bunun yerine 404 alırdınız.

Sorun eksik bir sayfayla değil, isteğin nasıl yapıldığıyla ilgili olduğu için 405 hatasını neredeyse her zaman sitenin geliştiricisinin düzeltmesi gerekir. Ziyaretçiler bu hatayla genellikle bir form gönderdikten veya güncelliğini yitirmiş bir bağlantıyı izledikten sonra karşılaşır.

405 Hatası Nasıl Görünür

Adım 1: Allow Başlığını Okuyun

Sunucuya o URL için hangi yöntemleri kabul ettiğini sorun. Ya bir OPTIONS isteği gönderin ya da başarısız olan isteği başlıkları gösterecek şekilde tekrarlayın:

# Bu URL hangi yöntemleri kabul ediyor?
curl -i -X OPTIONS https://example.com/api/contact

# Başarısız isteği tekrarlayın; durum koduna ve Allow başlığına bakın
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

DNS Robot'un HTTP Başlık Kontrolü aracı, bir URL'nin normal bir GET isteğine döndürdüğü durum kodunu ve başlıkları gösterir; bu da bir API yerine tarayıcıda bir sayfayı kontrol ederken işinize yarar.

Her sunucu bu kurala uymaz. Örneğin nginx'in yerleşik 405 sayfası Allow başlığı olmadan gönderilir; bu yüzden nginx'te bunun yerine URL'yi hangi location bloğunun işlediğini kontrol etmeniz gerekir (Çözüm 2).

Ziyaretçiyseniz

• Geri dönüp sayfayı yeniden yükleyin, ardından formu tekrar gönderin. Önbellekteki eski bir kopyadan yüklenen bir form, o zamandan beri değişmiş bir adrese gönderim yapabilir.

• Gönderdikten sonra sayfayı yenilemeyin. Bir form gönderiminin sonucu olan sayfayı yenilemek, yalnızca GET kabul eden bir URL'ye POST isteğini yeniden gönderebilir.

• Adreste yazım hatası olup olmadığını kontrol edin ya da sitenin ana sayfasını açıp yeniden gezinin.

• Sorunu bildirin. Sitedeki bir form her seferinde başarısız oluyorsa sorunu site sahibinin çözmesi gerekir; ona sayfanın adresini gönderin.

Çözüm 1: Doğru Yöntemi Doğru URL'ye Gönderin

Kodda en yaygın neden basit bir uyumsuzluktur: uç nokta yalnızca GET kabul ederken bir form veya fetch() çağrısı POST kullanır ya da istek API URL'si yerine sayfa URL'sine gider. Kodunuzdaki yöntemi Allow başlığıyla ve API'nin belgeleriyle karşılaştırın.

// Uç nokta yalnızca POST'a izin verir; bu yüzden GET (fetch'in varsayılanı) 405 döndürür
const res = await fetch("/api/contact", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Ana" }),
})
if (res.status === 405) console.log("Allowed:", res.headers.get("allow"))

Çözüm 2: nginx Statik Dosyalara Yapılan POST İçin 405 Döndürüyor

nginx'in statik dosya işleyicisi yalnızca GET ve HEAD isteklerine yanıt verir. Bir .html dosyasına ya da isteği uygulamanıza iletmek yerine dosya sunan bir location'a yapılan POST, 405 Not Allowed alır. Bu çoğu zaman bir formun action değeri statik bir sayfayı gösterdiğinde veya uygulamanız için tasarlanmış bir location bloğu eşleşmediğinde olur.

Asıl çözüm, POST isteğini doğru location bloğunda proxy_pass veya fastcgi_pass ile bir uygulamaya (PHP, Node, Python) göndermektir. URL'yi hangi bloğun işlediğini kontrol edin:

# Form gönderimleri statik dosya işleyicisine değil, uygulamaya ulaşmalı
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# Değişikliklerden sonra test edip yeniden yükleyin
# sudo nginx -t && sudo systemctl reload nginx

Çözüm 3: IIS, PUT ve DELETE İsteklerini Engelliyor (WebDAV)

IIS çalıştıran Windows sunucularında WebDAV modülü PUT ve DELETE fiillerini sahiplenir; bu yüzden REST API'ler (ASP.NET Web API ve diğerleri) bu istekler için HTTP Error 405.0 yanıtı verir. WebDAV kullanmıyorsanız onu web.config dosyasında siteniz için kaldırın:

<system.webServer>
  <modules>
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
  </handlers>
</system.webServer>

IIS Yöneticisi'nde sitenin İstek Filtreleme (Request Filtering) ayarlarını da kontrol edin (HTTP Verbs sekmesi); bu ayarlar belirli yöntemleri doğrudan reddedebilir (IIS bunları 405 değil, 404.6 olarak bildirir).

Çözüm 4: Yöntemi Rota İşleyicinize Ekleyin

Framework'ler, bir rota var olduğu halde kullanılan yöntem için bir işleyicisi olmadığında 405 döndürür:

• Next.js (App Router): bir route.ts dosyası yalnızca dışa aktardığı yöntemlere yanıt verir. GET dışa aktarılıp POST aktarılmamışsa bir POST isteği 405 döndürür. export async function POST(request: Request) { … } ekleyin.

• Flask: rotalar varsayılan olarak yalnızca GET kabul eder. @app.route("/contact", methods=["GET", "POST"]) kullanın.

• Django: sınıf tabanlı görünümler, eşleşen bir işleyicisi olmayan yöntemler için 405 döndürür (bir post() metodu ekleyin); require_http_methods dekoratörü de aynısını yapar.

• Express: varsayılan olarak eşleşmeyen bir yöntem 405'e değil, 404'e düşer. API'nizin 405 döndürmesi gerekiyorsa Allow başlığını ayarlayan, her şeyi yakalayan bir işleyici ekleyin.

Çözüm 5: CORS Preflight (OPTIONS) İsteklerini İşleyin

Bir web sayfası başka bir alan adındaki bir API'yi JSON veya özel başlıklarla çağırdığında, tarayıcı önce bir OPTIONS preflight (ön kontrol) isteği gönderir. API bu OPTIONS isteğine 405 ile yanıt verirse tarayıcı bir CORS hatası bildirir ve asıl isteği hiç göndermez; oysa asıl uç nokta çalışacaktı.

API'nin bu rotalar için OPTIONS isteklerine doğru Access-Control-Allow-Methods ve Access-Control-Allow-Headers başlıklarıyla birlikte 204 veya 200 ile yanıt vermesini sağlayın. Çoğu framework'te bunu sizin yerinize yapan bir CORS ara yazılımı bulunur. Örneğin DNS Robot'un kendi DNS Sorgulama API'si, preflight isteğine 204 ve CORS başlıklarıyla yanıt verir; böylece tarayıcılar onu herhangi bir siteden çağırabilir.

405 ile 400, 403, 404 ve 501 Arasındaki Farklar

İlgili rehberler: 400 Bad Request, 403 Forbidden ve 401 Unauthorized.