ما هو كود الحالة 406 غير مقبول؟ بروتوكول المدقق في الأكل

في المفردات الغنية لأكواد حالة HTTP، تبرز بعض الأكواد أكثر من غيرها بينما تؤدي بعضها الآخر أدوارًا حيوية بصمت لضمان سلاسة الاتصالات بين العميل والخادم. رمز الحالة 406 Not Acceptable هو أحد هؤلاء الأبطال المجهولين. قد لا يظهر بالقدر الذي تظهر به الرموز الشائعة 404 أو 500، ولكن فهم غرضه يمكن أن يحسن بشكل كبير فهمك لمفاوضات المحتوى ويعزز مرونة تطبيقات الويب وواجهات برمجة التطبيقات (APIs) الخاصة بك.

قد يبدو رمز الحالة 406 Not Acceptable كرسالة غامضة من خادمك. ولكن بمجرد أن تفهم ما يعنيه، يصبح إشارة قوية تساعدك على تصميم واجهات برمجة تطبيقات أنظف وأكثر قابلية للتنبؤ وأكثر سهولة في الاستخدام.

يمثل رمز الحالة هذا انهيارًا في الاتصال ضمن الرقصة المعقدة لعملية مفاوضات المحتوى حيث يتفق العملاء والخوادم على أفضل تنسيق لتبادل البيانات.

في هذه المدونة، سنتعمق في معنى HTTP 406 Not Acceptable، ولماذا يحدث، وكيف تؤثر مفاوضات المحتوى عليه، وكيف يمكنك، كمطور أو مستهلك لواجهة برمجة تطبيقات، التعامل معه بفعالية. قد يستغرق تصحيح الأخطاء الغريبة مثل 406 Not Acceptable وقتًا طويلاً بدون الأدوات المناسبة. لهذا السبب أوصي بـ Apidog. إنها منصة API مجانية وشاملة تتيح لك تصميم ومحاكاة واختبار وتصحيح وتوثيق واجهات برمجة التطبيقات بسهولة، لذلك ستعرف بالضبط سبب حصولك على 406 وكيفية إصلاحه بسرعة.

💡

إذا كنت ترغب في استكشاف واختبار واجهات برمجة التطبيقات بسلاسة، بما في ذلك الاستجابات ذات الحالة 406، قم بتنزيل Apidog مجانًا. Apidog هي أداة أساسية لاختبار وتوثيق واجهات برمجة التطبيقات تجعل التحقيق في أكواد حالة HTTP مثل 406 أمرًا سهلاً وفعالاً.

زر

الآن، دعنا نستكشف عالم مفاوضات المحتوى ورمز حالة HTTP 406 Not Acceptable.

المشكلة: الجميع يريد البيانات بطريقته الخاصة

في الأيام الأولى للويب، كانت الخوادم تقدم عادةً تنسيقًا واحدًا لمواردها، وعادةً ما يكون HTML. ولكن مع تطور الويب، ظهر عملاء مختلفون باحتياجات مختلفة:

متصفحات الويب تريد HTML
تطبيقات الجوال تريد JSON
قد ترغب الخدمات الأخرى في XML
قد يحتاج بعض العملاء إلى تصدير PDF أو CSV

رمز الحالة 406 موجود لأنه في بعض الأحيان يطلب العميل تنسيقًا لا يمكن للخادم توفيره ببساطة لهذا المورد المعين.

ماذا يعني HTTP 406 Not Acceptable بالفعل؟

يشير رمز الحالة 406 Not Acceptable إلى أن الخادم لا يمكنه إنتاج استجابة تتطابق مع قائمة القيم المقبولة المحددة في رؤوس مفاوضات المحتوى الاستباقية للطلب، وأن الخادم غير مستعد لتوفير تمثيل افتراضي.

بشكل أبسط: "لقد أخبرتني بالضبط ما هي التنسيقات التي ستقبلها، ولا يمكنني توفير المورد بأي من تلك التنسيقات."

يجب أن تتضمن استجابة 406 الصحيحة معلومات حول التنسيقات التي يمكن للخادم توفيرها للمورد المطلوب. يتم ذلك عادةً باستخدام الرؤوس أو في نص الاستجابة.

إليك كيف قد تبدو استجابة 406:

HTTP/1.1 406 Not AcceptableContent-Type: text/htmlVary: Accept
<html><head><title>406 Not Acceptable</title></head><body><h1>Not Acceptable</h1><p>This resource is available in the following formats:</p><ul><li>application/json</li><li>application/xml</li></ul></body></html>

بالنسبة لواجهات برمجة التطبيقات، من المفيد أكثر إرجاع استجابة منظمة:

HTTP/1.1 406 Not AcceptableContent-Type: application/jsonVary: Accept
{
  "error": "not_acceptable",
  "message": "The requested resource is not available in the requested format.",
  "available_formats": [
    "application/json",
    "application/xml"
  ]
}

الأمر لا يتعلق بما إذا كان الطلب صالحًا. بل يتعلق بما إذا كان نوع الاستجابة مقبولاً.

سحر مفاوضات المحتوى: كيف تعمل رؤوس Accept

لفهم 406، نحتاج إلى فهم كيف تخبر العملاء الخوادم بالتنسيقات التي يفضلونها. يحدث هذا من خلال رأس Accept.

رأس Accept في العمل

عندما يقدم العميل طلبًا، يمكنه تحديد أنواع المحتوى التي يمكنه التعامل معها وتلك التي يفضلها:

مثال بسيط:

GET /api/users/123 HTTP/1.1Accept: application/json

هذا يقول: "أريد بيانات المستخدم، وأنا أفهم JSON فقط."

مثال أكثر تعقيدًا:

GET /api/users/123 HTTP/1.1Accept: application/json, text/html;q=0.9, application/xml;q=0.8

هذا يقول: "أفضل JSON، ولكن يمكنني أيضًا التعامل مع HTML (بأفضلية 90%) و XML (بأفضلية 80%)."

يتراوح المعامل q (قيمة الجودة) من 0 إلى 1، حيث 1 هو الأكثر تفضيلاً.

عندما تفشل المفاوضات

يحدث خطأ 406 عندما ينظر الخادم إلى رأس Accept ويدرك:

لديه المورد الذي يريده العميل
لا يمكنه توفيره بأي من التنسيقات التي حددها العميل
غير مستعد لإرسال تنسيق افتراضي (مثل إرسال JSON إلى عميل يقبل XML فقط)

كيف يتناسب 406 Not Acceptable مع مفاوضات المحتوى؟

عندما يرسل العميل طلب HTTP يتضمن رؤوس Accept تحدد أنواع الوسائط المقبولة (على سبيل المثال، طلب استجابات JSON فقط)، سيحاول الخادم تقديم المحتوى وفقًا لذلك.

إذا كان الخادم لا يستطيع توفير أي محتوى مقبول يتوافق مع المعايير، فإنه يستجيب بـ:

textHTTP/1.1 406 Not Acceptable Content-Type: text/html

في هذه المرحلة، يعني ذلك أن الخادم يرفض الطلب لأن لا يوجد تمثيل محتوى متاح يطابق تفضيلات العميل.

لماذا تعيد الخوادم 406 بدلاً من 200 OK

قد تفكر: لماذا لا تعيد شيئًا ما، حتى لو لم يكن التنسيق المفضل؟

إليك سبب إعادة الخوادم 406:

لفرض قواعد مفاوضات محتوى صارمة.
لمنع إرسال البيانات بتنسيق قال العميل صراحة إنه لا يمكنه قبوله.
لتسهيل تصحيح الأخطاء للمطورين عن طريق الإشارة إلى رؤوس Accept غير المتطابقة.

الأسباب الشائعة لاستجابة 406

إليك بعض الأسباب النموذجية التي ستجعلك ترى 406 Not Acceptable:

رؤوس Accept غير متطابقة ← يطلب العميل application/xml ولكن الخادم يدعم application/json فقط.
عملاء API قديمة ← استخدام حزم SDK أقدم تتوقع تنسيقات استجابة مختلفة.
تكوين خادم غير صحيح ← مفاوضات المحتوى ليست معدة بشكل صحيح.
غرائب الإطار ← بعض الأطر (مثل Django أو Rails) تفرض معالجة صارمة لرأس Accept.
معالجة أخطاء مخصصة خاطئة ← مرشحات صارمة بشكل مفرط على تنسيقات الاستجابة.

سيناريوهات واقعية تؤدي إلى أخطاء 406

1. تعارضات إصدارات API

تخيل واجهة برمجة تطبيقات (API) تقدم JSON فقط في إصدارها الثاني (v2)، لكن العميل لا يزال يتوقع XML من أيام الإصدار الأول (v1):

GET /v2/products/456 HTTP/1.1Accept: application/xmlHTTP/1.1 406 Not AcceptableContent-Type: application/json
{
  "error": "This API version only supports JSON",
  "available_formats": ["application/json"]
}

2. تكوين العميل المفرط في التقييد

قد يكون تطبيق الجوال مبرمجًا بشكل صارم لقبول JSON فقط، ولكنه يواجه خادمًا يقدم بعض الموارد كـ XML فقط:

GET /reports/quarterly-sales HTTP/1.1Accept: application/jsonHTTP/1.1 406 Not Acceptable

(قد يكون التقرير متاحًا فقط بتنسيق CSV أو PDF)

3. عدم وجود خيار احتياطي افتراضي

تم تكوين بعض الخوادم لتكون صارمة بشأن مفاوضات المحتوى وترفض تخمين التنسيق الذي يجب إرجاعه عند فشل المفاوضات.

كيف تتعامل الخوادم عادةً مع 406؟

من المثير للاهتمام أن بعض الخوادم تتجاهل مفاوضات المحتوى الصارمة وتعود إلى استجابة افتراضية بدلاً من الاستجابة بـ 406.

ومع ذلك، فإن واجهات برمجة التطبيقات RESTful الصارمة أو الخدمات التي تؤكد على الاتصال الدقيق قد تعيد 406 عندما لا يمكن تلبية متطلبات العميل.

406 Not Acceptable مقابل رموز الحالة ذات الصلة

لتوضيح دور 406، دعنا نلقي نظرة على حالات HTTP ذات الصلة:

رمز الحالة	المعنى	متى يستخدم
400 Bad Request	صيغة خاطئة أو طلب غير صالح	لا يمكن فهم الطلب
406 Not Acceptable	طلب صالح لكن الخادم لا يمكنه تلبية رؤوس القبول	فشل مفاوضات المحتوى
415 Unsupported Media Type	الخادم لا يمكنه معالجة نوع المحتوى الذي أرسله العميل	نوع وسائط نص الطلب غير صالح
الفرق بين 406 و 415	406 يتعلق بنوع الاستجابة، 415 يتعلق بنوع نص الطلب	—

كيف يجب على العملاء التعامل مع استجابات 406؟

يجب على العملاء الذين يتلقون 406 أن:

يتحققوا من رؤوس مفاوضات المحتوى التي أرسلوها.
يعدلوا رؤوس Accept لتشمل أنواع وسائط أوسع.
ينفذوا آليات احتياطية لطلب التنسيقات الافتراضية (مثل /*).
يحترموا قدرات الخادم ويحدوا من الطلبات وفقًا لذلك.
يوفروا رسائل سهلة الاستخدام إذا تعذر تقديم أنواع محتوى محددة.

ماذا يمكن للمطورين فعله لتجنب أو التعامل مع 406؟

تقديم تمثيلات محتوى متعددة (JSON، XML، HTML) حيثما أمكن.
تنفيذ منطق مفاوضات من جانب الخادم للعودة إلى الوضع الطبيعي بدلاً من الرفض.
توثيق أنواع الوسائط المدعومة بوضوح لمستهلكي واجهة برمجة التطبيقات.
تسجيل استجابات 406 لتحديد عدم توافق العملاء أو المشكلات.
استخدام المكتبات أو الأطر التي تدعم مفاوضات المحتوى المضمنة.

صفحات ورسائل خطأ 406 مخصصة

بالنسبة لمواقع الويب وواجهات برمجة التطبيقات، فإن تقديم استجابات خطأ 406 ذات معنى ومفيدة يحسن تجربة المطور والمستخدم:

تضمين اقتراحات حول أنواع المحتوى المدعومة.
توفير روابط أو أمثلة للاستخدام الصحيح.
استخدام لغة واضحة في رسائل الخطأ.
تخصيص صفحات الخطأ لتكون متوافقة مع هوية الموقع.

اختبار مفاوضات المحتوى باستخدام Apidog

يعد اختبار كيفية تعامل واجهة برمجة التطبيقات الخاصة بك مع رؤوس Accept المختلفة أمرًا بالغ الأهمية لبناء تطبيقات قوية. يجعل Apidog هذه العملية مباشرة وفعالة.

باستخدام Apidog، يمكنك:

تعديل الرؤوس بسهولة: إضافة وتعديل رؤوس Accept بسرعة لاختبار كيفية استجابة خادمك لطلبات أنواع المحتوى المختلفة.
اختبار تنسيقات متعددة: إنشاء مجموعة من الاختبارات لنفس نقطة النهاية باستخدام رؤوس Accept مختلفة (JSON، XML، HTML) لضمان تغطية شاملة.
التحقق من استجابات 406: إرسال رؤوس Accept مقيدة عمدًا للتحقق من أن خادمك يعيد استجابات 406 صحيحة بمعلومات خطأ مفيدة.
أتمتة اختبارات مفاوضات المحتوى: إنشاء مجموعات اختبار تتحقق تلقائيًا من أن واجهة برمجة التطبيقات الخاصة بك تتعامل بشكل صحيح مع طلبات أنواع المحتوى المختلفة وتعيد رموز الحالة المناسبة.
تصحيح السيناريوهات المعقدة: استخدم تسجيل Apidog المفصل لفهم سبب حدوث خطأ 406 بالضبط وما هي التنسيقات التي يدعمها الخادم بالفعل.

زر

يضمن هذا النهج المنهجي أن واجهة برمجة التطبيقات الخاصة بك يمكنها التعامل بمرونة مع العملاء ذوي متطلبات التنسيق المختلفة. باختصار: بدلاً من التخبط في الظلام، ستعرف بالضبط ما هو مقبول. قم بتنزيل Apidog مجانًا وعزز إنتاجيتك في استكشاف أخطاء مفاوضات المحتوى وسيناريوهات 406.

أفضل الممارسات للتعامل مع أخطاء 406

لمطوري الخوادم:

توفير معلومات خطأ مفيدة: عند إرجاع 406، قم دائمًا بتضمين معلومات حول التنسيقات التي تدعمها. يساعد هذا مطوري العميل على إصلاح طلباتهم.
استخدام رأس Vary: قم بتضمين رأس Vary: Accept في استجاباتك للإشارة إلى أن محتوى الاستجابة يختلف بناءً على رأس Accept. يساعد هذا أنظمة التخزين المؤقت على العمل بشكل صحيح.
النظر في السلوك الافتراضي: بينما تسمح مواصفات HTTP للخوادم بإرجاع تمثيل افتراضي، تختار العديد من واجهات برمجة التطبيقات الحديثة أن تكون صارمة وتُرجع 406 لإجبار العملاء على أن يكونوا صريحين بشأن متطلباتهم.
توثيق التنسيقات المدعومة: وثّق بوضوح أنواع المحتوى التي تدعمها واجهة برمجة التطبيقات الخاصة بك لكل نقطة نهاية.

لمطوري العملاء:

كن مرنًا في رؤوس Accept: ما لم يكن لديك سبب محدد، قم بتضمين تنسيقات متعددة في رأس Accept الخاص بك مع قيم جودة مناسبة.
تعامل مع 406 بمرونة: عندما تتلقى 406، تحقق من الاستجابة بحثًا عن التنسيقات المتاحة وقم إما بتعديل طلبك أو عرض رسالة خطأ مفيدة للمستخدم.
امتلك منطقًا احتياطيًا: فكر في امتلاك منطق احتياطي يمكنه التعامل مع تنسيقات مختلفة إذا لم يكن التنسيق المفضل الأساسي متاحًا.

البطل المجهول لمفاوضات المحتوى

يعد رأس Vary حاسمًا لسلوك التخزين المؤقت الصحيح عند وجود مفاوضات المحتوى. عندما يضمّن الخادم Vary: Accept في استجابته، فإنه يخبر ذاكرات التخزين المؤقت أن محتوى الاستجابة يعتمد على قيمة رأس Accept.

يمنع هذا ذاكرة التخزين المؤقت من تقديم استجابة JSON بشكل غير صحيح لعميل طلب XML، أو العكس.

تأثير استجابات 406 على تحسين محركات البحث (SEO)

بشكل عام، لا يؤثر 406 على تحسين محركات البحث بشكل كبير لأن محركات البحث عادةً ما تتعامل مع مفاوضات المحتوى بقوة وتفضل الاستجابات الصالحة. ومع ذلك، فإن واجهات برمجة التطبيقات أو مواقع الويب غير المكونة بشكل صحيح والتي تُرجع 406 بشكل متكرر يمكن أن تحبط برامج الزحف أو المستخدمين.

تصميم API الحديث و 406

في تصميم واجهة برمجة التطبيقات RESTful الحديثة، تطور استخدام 406:

العديد من واجهات برمجة التطبيقات تعتمد على JSON فقط ولا تهتم بمفاوضات المحتوى، مما يجعل 406 نادرًا.
أصبحت إدارة الإصدارات عبر عناوين URL (مثل /v1/، /v2/) أكثر شيوعًا من مفاوضات المحتوى لتغييرات التنسيق.
واجهات برمجة التطبيقات ذات الوسائط المتعددة (HATEOAS) غالبًا ما تستخدم مفاوضات المحتوى لتقديم تمثيلات مختلفة لنفس المورد.

ومع ذلك، يظل 406 ذا صلة بـ:

واجهات برمجة التطبيقات التي تقدم تنسيقات بيانات متعددة
أنظمة إدارة المحتوى التي يمكنها إخراج HTML و JSON و XML
الخدمات التي توفر تصدير البيانات بتنسيقات مختلفة

استكشاف أخطاء 406 وإصلاحها

تحقق من رؤوس طلب العميل بحثًا عن قيم Accept المقيدة.
راجع التنسيقات المدعومة من الخادم ومنطق التفاوض.
استخدم أدوات مثل Apidog لتجربة مجموعات رؤوس مختلفة.
اضبط تكوينات العميل أو الخادم لتوسيع خيارات المحتوى المقبولة.

اعتبارات الأمان حول 406

يمنع الخوادم من تسريب تنسيقات غير مقصودة.
يساعد على تجنب ثغرات التطفل على المحتوى.
يمكن تكوينه لرفض التنسيقات الخطرة مثل text/html في واجهات برمجة التطبيقات.

الخاتمة: تبني HTTP 406 Not Acceptable للاتصال الدقيق

يمثل رمز الحالة HTTP 406 Not Acceptable مبدأً مهمًا في بنية الويب: التواصل الواضح بين العملاء والخوادم حول قدراتهم ومتطلباتهم. إنه ليس خطأ يجب الخوف منه، بل هو آلية لضمان حدوث تبادل البيانات بتنسيقات مفهومة بشكل متبادل.

بينما قد لا تواجه 406 يوميًا، فإن فهمها يجعلك مواطن ويب أفضل. إنها تعلم أهمية أن تكون صريحًا بشأن متطلبات تنسيق البيانات والتعامل مع مفاوضات التنسيق بمرونة.

بالنسبة لمطوري واجهة برمجة التطبيقات، يؤدي التنفيذ الصحيح لمفاوضات المحتوى واستجابات 406 إلى واجهات برمجة تطبيقات أكثر قوة ومرونة. وبالنسبة لمطوري العملاء، يضمن فهم كيفية التعامل مع أخطاء 406 أن تطبيقاتهم يمكنها التكيف مع قدرات الخادم المختلفة.

في عالم يجب أن تتدفق فيه البيانات بين أنظمة ومنصات متنوعة، أصبحت القدرة على التفاوض على تنسيق المحتوى أكثر قيمة من أي وقت مضى. وعندما تحتاج إلى اختبار هذه المفاوضات وإتقانها، توفر أداة مثل Apidog البيئة المثالية لضمان تواصل تطبيقاتك بفعالية، بغض النظر عن تفضيلات التنسيق.

زر