413 Request Entity Too Large: Nedenleri ve Çözümleri

413 Payload Too Large ne anlama gelir

RFC 9110, mevcut adı 413 Content Too Large olarak tanımlar, ancak eski 413 Payload Too Large ve daha eski 413 Request Entity Too Large ikisi de aynı durum koduna atıfta bulunur ve sunucular, çatılar ve hata sayfaları genelinde hâlâ görünür. İfade ne olursa olsun, anlam aynıdır: isteğin kendisi sözdizimsel olarak iyi durumdaydı, ama gövdesi sunucu onu işlemek için kabul etmeden önce bir boyut sınırını aştı. Bu en çok dosya yüklemelerinde olur, ama toplu bir API yükü dahil büyük gövdeli herhangi bir istekte olabilir.

Hata nasıl görünür

Tarayıcılar genellikle kaynak sunucunun veya kenarın geri gönderdiği düz hata sayfasını gösterir; bir bağlantı hatasında olduğu gibi buna özel tarayıcı arayüzü yoktur. Özellikle JavaScript ile oluşturulmuş bir dosya yüklemesi için, yanıt sadece ağ sekmesinde görünür şekilde bir formda sessizce başarısız olması yaygındır. Komut satırından, yanıt bunu doğrudan doğrular:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Bir istek CDN'de, web sunucusunda, veya uygulamada engellenebileceğinden ve her biri onu farklı şekilde günlüğe kaydedebileceğinden, sunucu erişim ve hata günlükleri, ilgili tam boyutu ve hangi katmanın onu reddettiğini doğrulamak için en güvenilir yerdir.

413'e ne sebep olur

• nginx'in client_max_body_size'ı. Varsayılan 1 MB'dir, ki bu açıkça yükseltilene kadar neredeyse her gerçek dosya yüklemesinin tökezlemesine yetecek kadar küçüktür:

  client_max_body_size 20M;

• Apache'nin LimitRequestBody'si. Dizin başına veya genel olarak ayarlanır, ve nginx gibi, kimsenin kasıtlı olarak değiştirmediği çoğu uygulamanın aştığı bir boyuta varsayılan olarak ayarlıdır.
• PHP'nin upload_max_filesize ve post_max_size'ı. php.ini'de ikisi de yükleme için yeterince büyük olması gereken iki ayrı ayar; post_max_size en az upload_max_filesize kadar büyük olmalı yoksa ikinci ayar birinciyi sessizce sınırlar.
• IIS'in maxAllowedContentLength'ı. web.config'de requestLimits altında ayarlanır, varsayılan olarak yaklaşık 30 MB, ve ASP.NET'in kendi maxRequestLength ayarından ayrı, ki bu farklı birimler kullanır ve onunla birlikte yükseltilmesi gerekir.
• Cloudflare'in plan tabanlı yükleme sınırı. Free ve Pro planlar, kaynak sunucunun aksi takdirde kabul edeceğine bakılmaksızın istek gövdesi boyutunu 100 MB'a sınırlar, ve bu sınır kaynağın kendi yapılandırmasından yükseltilemez; Cloudflare tarafında ele alınması veya proxy'yi atlayan doğrudan bir yükleme yoluyla dolaşılması gerekir.
• API ağ geçidi yük sınırları. Yönetilen API ağ geçitleri genellikle istek gövdelerini geleneksel bir web sunucusunun izin vereceğinden çok daha aşağıya, genellikle tek haneli megabaytlarda, sınırlar, ki bu var olan bir yükleme özelliğini yeni bir ağ geçidinin arkasına taşıyan takımları yakalar.

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

Bu neredeyse hiçbir zaman bir ziyaretçinin yanlış bir şey yaptığı anlamda bir hata değildir; yükledikleri dosya basitçe zincirde bir yerde var olan bir sınırdan daha büyüktür, ve düzeltme o katmana sahip olana aittir. Aynı dosya bir ortamda gayet iyi yükleniyor ve diğerinde başarısız oluyorsa, yoldaki her katmanı karşılaştırın, çünkü nginx, PHP ve bir CDN'in her birinin farklı bir sınırı olabilir ve en küçük olan kazanır. Amaçlanan sınırınıza yakın bir istek gövdesiyle, kendi ağınızın dışından gönderilen bir HTTP kontrolü çalıştırmak, herhangi bir tek yapılandırma dosyasına güvenmek yerine gerçek tavanın uçtan uca ne olduğunu doğrular.

413 hatası nasıl düzeltilir

Bir ziyaretçiyseniz

1. Yüklemeden önce dosyayı sıkıştırın, özellikle görünür kalite kaybı olmadan tipik boyutlarda dramatik şekilde küçülen görüntüler ve videolar.
2. Site parçalı veya devam ettirilebilir yüklemeleri destekliyorsa büyük bir yüklemeyi daha küçük parçalara bölün, tek çok büyük bir istek göndermek yerine.
3. Yayınlanmışsa sitenin belirtilen yükleme sınırını kontrol edin, çünkü bazı 413'ler tasarlandığı gibi çalışıyordur ve düzeltme basitçe daha küçük bir dosyadır.

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

1. Sadece birini değil her katmanın sınırını birlikte yükseltin. Tek bir istek tipik olarak bir CDN, bir web sunucusu ve bir uygulama çalışma zamanından geçer, ve o zincirde herhangi bir yerde yapılandırılmış en küçük sınır gerçek tavanı belirler.
2. Varsayılanlara güvenmek yerine nginx ve Apache'yi açıkça ayarlayın:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. PHP'nin iki ayarını eşleştirin. Hem upload_max_filesize'ı hem de post_max_size'ı yükseltin, ve ikincisinin birinciye eşit veya ondan büyük olduğundan emin olun.
4. IIS'in requestLimits'ini ve ASP.NET'in maxRequestLength'ini web.config'de birlikte güncelleyin, çünkü ikisi de aynı şeyi farklı birimlerle ölçer ve ikisinin de yükseltilmesi gerekir.
5. Cloudflare'in plan sınırının etrafından dolanmak için gerçekten büyük dosyalar için, proxy'lenen istek yolunu tamamen atlayarak, imzalı bir URL ile depolamaya doğrudan yükleyin, o plan katmanının açığa çıkarmadığı bir sınırı yükseltmeye çalışmak yerine.
6. Uygulamanızın önünde bir tane oturuyorsa, API ağ geçidinin kendi yük sınırını arka uç hizmetten ayrı olarak kontrol edin; daha cömert kendi uygulama ayarlarınız hiç uygulanma şansı bulamadan bir isteği reddedebilir.

Bir 413'ün gerçek kullanıcıları engellemesi nasıl önlenir

Çok düşük ayarlanmış bir sınır, büyük bir dosyası olan biri ona çarpana kadar gözden kaçırması kolaydır, ve o zamana kadar bir yapılandırma uyuşmazlığı yerine bozuk bir yükleme özelliği gibi görünür. Amaçlanan boyut sınırınıza yakın bir istek gönderen, beklenen durum kodu üzerinde bir doğrulaması olan zamanlanmış bir HTTP kontrolü, CDN'e, web sunucusuna veya uygulama yapılandırmasına yapılan herhangi bir değişiklikten sonra tüm zincirin hâlâ onu kabul ettiğini doğrular. Birden fazla konumdan izleme ile birleştirildiğinde, sadece belirli kenar düğümlerinde geçerli olan bir CDN düzeyindeki sınırı da yakalar.

İlgili hatalar

Bazı sunucuların aynı aşırı büyük gövde koşulu için 413 yerine döndürdüğü 400 Bad Request'e, daha geniş aile için 4xx genel bakışına, ve bu partide başka yerde 406 Not Acceptable'a bakın.

Sık sorulan sorular

413 Payload Too Large, 413 Request Entity Too Large ile aynı mı?

Evet. RFC 9110, durum metnini 413 Content Too Large olarak yeniden adlandırdı, ama her iki eski ad da aynı durum koduna ve anlamına atıfta bulunur, ve her üç ifade de sunucu yazılımının sürümüne bağlı olarak hâlâ pratikte görünür.

nginx'in client_max_body_size'ını yükseltmeme rağmen yüklemem neden başarısız oluyor?

Zincirdeki başka bir katman, yaygın olarak PHP'nin post_max_size'ı, bir CDN'in sabit plan sınırı, veya bir API ağ geçidi, muhtemelen bağımsız olarak daha küçük bir sınır uygular. İstemci ile uygulama arasındaki her katmanın, sadece değiştirdiğiniz olanın değil, boyuta izin vermesi gerekir.

Free veya pro planda Cloudflare'in 100 MB sınırını yükseltebilir miyim?

Kaynak sunucunun kendi yapılandırmasından değil; o tavan plan katmanı tarafından sabitlenmiştir. Genel çözüm, büyük dosyaları proxy'lenen istek yolunu atlayan imzalı bir URL kullanarak doğrudan depolamaya yüklemektir.

413 bir güvenlik engeli olarak mı sayılır?

Tipik olarak değil. Genellikle savunmacı bir kuraldan çok basit bir kaynak sınırıdır, ancak bazı WAF'lar bir isteği engelleyip engellemeyeceğine karar verirken alışılmadık derecede büyük gövdeleri birkaç sinyalden biri olarak kullanır.

Hiç ayarlamadıysam makul bir varsayılan yükleme sınırı nedir?

Evrensel bir sayı yoktur; tamamen uygulamanızın meşru olarak kabul etmesi gerekene bağlıdır. Her katmanın varsayılanını yerinde bırakmak yerine, en büyük beklenen meşru dosyanıza dayanarak onu kasıtlı olarak ayarlayın.