Preflight Requests في CORS: لماذا OPTIONS يفشل قبل الطلب الحقيقي

عندما يظهر في DevTools أن POST لم يُرسل، قد يكون OPTIONS preflight هو الذي فشل. المتصفح يستخدمه للطلبات غير البسيطة حتى يسأل الخادم هل يسمح بال ـorigin وال method وال headers. أدوات server-side مثل curl لا تطبق CORS، لذلك نجاحها لا يثبت نجاح الصفحة.

اعرف متى يحدث Preflight

Methods مثل PUT و DELETE أو headers مخصصة و content-types معينة تخرج من simple request وتطلق OPTIONS. المتصفح يضيف Access-Control-Request-Method و Headers.

اقرأ Response Headers

تحقق من Access-Control-Allow-Origin و Methods و Headers. wildcard لا يعمل مع credentials في حالات معينة. القيمة يجب أن تطابق origin الفعلي حسب السياسة.

فرق فشل الشبكة من CORS

إذا OPTIONS نفسها 500 أو timeout فالمشكلة server/proxy أولًا. إذا 204 لكن header ناقص فالمشكلة policy. DevTools Console عادة يشرح سبب الحجب.

راجع Credentials

مع cookies أو Authorization تحتاج إعداد credentials في fetch وخادم يسمح بها. Access-Control-Allow-Credentials مع origin صريح غالبًا ضروري. لا تستخدم * بلا فهم.

انتبه لل Cache

Preflight responses قد تُcache عبر Access-Control-Max-Age. عند تعديل policy قد ترى behavior قديمًا. اختبر نافذة نظيفة أو انتظر حسب الحاجة.

اختبر من origin الحقيقي

فتح HTML ك file:// أو من localhost مختلف لا يمثل production. شغل frontend على origin يشبه البيئة المستهدفة حتى تختبر policy الصحيحة.

اختبر تأثير CDN و Vary: Origin على CORS

حتى إذا كانت إعدادات التطبيق صحيحة، يمكن أن يخزن CDN response تحمل Access-Control-Allow-Origin لموقع واحد ثم يعيدها لطلب Origin مختلف إذا لم يكن cache key أو Vary مضبوطًا. اختبر Origin A ثم Origin B على نفس URL وراقب header وال cache status. إذا كان الخادم يعكس Origin ديناميكيًا، يجب أن تكون طبقة الكاش واعية بهذا الاختلاف. كذلك تحقق أن error responses مثل 401 و 500 تحمل CORS headers المناسبة إذا تريد frontend قراءة تفاصيلها؛ أحيانًا happy path ينجح بينما الأخطاء تظهر ك ـCORS generic بسبب missing header في مسار الاستثناء. هذه الاختبارات تنقل التشخيص من كود fetch فقط إلى المسار الكامل عبر proxy/CDN.

تحقق من Methods و Headers في Error Paths

قد يجيب preflight لل ـGET بصورة صحيحة لكنه يرفض PUT أو header جديدًا فقط. أنشئ جدولًا لل methods الفعلية وال headers التي يستخدمها frontend واختبر كل combination المهم. لا تعلن السماح ب ـDELETE إذا التطبيق لا يحتاجه. مبدأ أقل سماح ينطبق على CORS أيضًا ويقلل سطح الطلبات المقبولة من Origins خارجية.

من المثال إلى تطبيق يمكن صيانته

في «Preflight Requests في CORS: لماذا OPTIONS يفشل قبل الطلب الحقيقي» جرّب الحل على حالة صغيرة ثم أضف failure path واضحًا واختبارًا آليًا يحمي السلوك المتوقع. حدّد contract للمدخلات والمخرجات، وتعامل مع القيم الناقصة قبل الوصول إلى طبقة التنفيذ. إذا كان الحل يتعامل مع API أو ملف أو DOM، أضف logging مختصرًا يوضح المرحلة وكود الخطأ دون بيانات حساسة. بعد ذلك اختبر التوافق مع نسخة سابقة أو بيئة مختلفة. هذه الخطوات تجعل المثال مفيدًا في مشروع حقيقي بدل أن يبقى snippet يعمل فقط في المسار المثالي.