محتوای آموزشی وبلاگ نت‌آرام
یک درخواست کوچک به API اکسپرس موفق است، اما با بزرگ‌ترشدن متن یا آپلود، پاسخ
413 Request Entity Too Large دریافت می‌کنید. این پاسخ یعنی یکی از بخش‌های مسیر، اندازه درخواست را بیشتر از سقف مجاز دیده است. ممکن است محدودیت در Express، ابزار آپلود، Nginx، سرویس CDN یا پنل هاست باشد.راه‌حل، بی‌نهایت‌کردن همه سقف‌ها نیست. اول نوع درخواست و محل پاسخ را مشخص می‌کنیم، بعد فقط سقف لازم را متناسب با حافظه و سیاست برنامه تغییر می‌دهیم. تمام نمونه‌ها را ابتدا در محیط آزمایشی اجرا کنید.
۱. مشخص کنید چه چیزی ارسال می‌شود
در ابزار توسعه مرورگر، زبانه Network را باز و درخواست ناموفق را انتخاب کنید. آدرس، روش درخواست،
Content-Type، اندازه تقریبی و پاسخ را ببینید. داده application/json با فرم فایل multipart/form-data فرق دارد. همچنین خطای ۴۱۳ با ۴۰۰ مربوط به JSON نامعتبر و ۵۰۲ مربوط به خرابی ارتباط با برنامه یکی نیست.زمان دقیق درخواست و آدرس بدون اطلاعات محرمانه را یادداشت کنید. پاسخ HTML با نام وب‌سرور می‌تواند سرنخی از پراکسی باشد، اما صفحه خطای سفارشی و CDN ممکن است ظاهر را تغییر دهند؛ نام ظاهری پاسخ اثبات قطعی نیست. گزارش برنامه و پراکسی در همان زمان را مقایسه کنید. اگر درخواست اصلاً به برنامه نرسیده، سقف یک لایه جلوتر محتمل است.
۲. درخواست JSON را در خود Express محدود و آزمایش کنید
در پروژه آزمایشی می‌توانید برای یک مسیر مشخص parser با سقف مورد نیاز تعریف کنید:
کد / دستورconst express = require('express');
const app = express();
app.post('/api/data', express.json({ limit: '256kb' }), (req, res) => {
res.json({ received: true });
});
app.use((err, req, res, next) => {
if (err.type === 'entity.too.large') {
return res.status(413).json({ error: 'Request is too large' });
}
next(err);
});
این تکه فقط نمونه middleware است و برای اجرای کامل باید با ساختار و روش شروع برنامه خودتان ادغام شود. اگر
express.json() سراسری با سقف کوچک‌تر قبل از این مسیر درخواست را بخواند، ممکن است همان زودتر خطا بدهد. ترتیب middlewareها و مسیرها را بررسی کنید. مقدار 256kb صرفاً مثال است؛ سقف مناسب را از اندازه واقعی درخواست و ظرفیت حافظه تعیین کنید.برای آزمایش یک API آزمایشی که اجازه دریافت این داده را دارد، در ترمینال لینوکسی:
کد / دستورsample=$(mktemp)
python3 -c 'import json; print(json.dumps({"text":"a"*120000}))' > "$sample"
wc -c "$sample"
curl -i -H 'Content-Type: application/json' --data-binary "@$sample" 'https://example.com/api/data'
نشانی نمونه را با محیط آزمایشی خود عوض کنید.
wc اندازه فایل را نشان می‌دهد و curl همان داده را با روش POST می‌فرستد. این آزمون ممکن است داده‌ای در API ثبت کند؛ فقط از مسیری استفاده کنید که انجام آزمایش در آن مجاز و بی‌ضرر است. فایل موقت در مسیر چاپ‌شده با printf '%s\n' "$sample" قابل مشاهده است و پس از پایان می‌توانید همان فایل مشخص را پاک کنید.۳. فرم آپلود را با JSON اشتباه نگیرید
express.json فایل multipart/form-data را پردازش نمی‌کند. اگر از Multer یا ابزار مشابه استفاده می‌کنید، تنظیمات سقف فایل، تعداد فایل و خطاهای همان ابزار را بخوانید. برای مثال، خطای LIMIT_FILE_SIZE در Multer می‌تواند نشانه رسیدن فایل به سقف تنظیم‌شده باشد. نسخه کتابخانه و نحوه ذخیره‌سازی مهم است: نگه‌داشتن فایل‌های بزرگ در حافظه ممکن است برنامه را از کار بیندازد.محدودیت را تنها روی مسیر آپلود لازم بگذارید؛ کنترل نوع و اندازه فایل، دسترسی کاربر و فضای موقت را هم در نظر بگیرید. پسوند فایل به‌تنهایی برای اعتماد به محتوای آپلودشده کافی نیست. اگر سقف برنامه را تغییر دادید ولی پاسخ ۴۱۳ پیش از رسیدن به برنامه برمی‌گردد، مرحله پراکسی را بررسی کنید.
۴. سقف وب‌سرور یا پنل را با درخواست هماهنگ کنید
در سرور مستقلِ دارای Nginx، دستور
کد / دستورclient_max_body_size می‌تواند اندازه بدنه درخواست را در زمینه مناسب محدود کند. برای نمونه، در تنظیم آزمایشی همان مسیر:client_max_body_size 1m;
این مثال باید در
server یا location درست و با تنظیمات موجود ادغام شود؛ نام فایل و محل دقیق به نصب شما بستگی دارد. یک فایل پشتیبان و راه بازگشت داشته باشید، سپس با sudo nginx -t صحت نحوی را بررسی کنید. فقط پس از موفقیت آزمون و تأیید تأثیر بر سرویس، با روش استاندارد سرور تنظیم را reload کنید. این سقف بدنه کامل درخواست است؛ فرم multipart علاوه بر خود فایل، سربار و فیلد هم دارد.در هاست اشتراکی ممکن است به این تنظیم دسترسی نداشته باشید. اندازه درخواست، زمان و مسیر بدون توکن را برای پشتیبانی بفرستید و درباره سقف سرویس بپرسید؛ ایجاد فایل تنظیم نامعتبر در پوشه سایت الزاماً تنظیم Nginx را تغییر نمی‌دهد. CDN یا پراکسی دیگر هم ممکن است سقف جداگانه‌ای داشته باشد.
۵. مرز موفق و ناموفق را دوباره بیازمایید
یک درخواست کوچک‌تر از سقف توافق‌شده باید به برنامه برسد و پاسخ مورد انتظار بدهد. یک درخواست کمی بزرگ‌تر باید کنترل‌شده رد شود، بدون اینکه پردازش از حافظه خارج شود. درخواست واقعی کاربر را نیز پس از آزمون بررسی کنید و از ثبت محتوای حساس در گزارش خطا خودداری کنید.
اگر پس از تغییر برنامه با خطای بسته پیدا نشده روبه‌رو شدید، راهنمای Cannot find module در Node.js را بخوانید. برای امکانات سرویس هاست Node.js نت‌آرام و برای شرح خطاهای parser مستندات Express را ببینید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام