Blog

ما هو كود الحالة 417: فشل التوقع؟ المصافحة الفاشلة

INEZA Felin-Michel

INEZA Felin-Michel

15 أكتوبر 2025

ما هو كود الحالة 417: فشل التوقع؟ المصافحة الفاشلة

Apidog للمؤسسات

النشر على الخوادم المحلية

SSO و RBAC

متوافق مع SOC 2

استكشف Apidog للمؤسسات

أنت في مطعم ولديك احتياجات غذائية خاصة. قبل أن تطلب حتى، تقول للنادل: "لن آكل هنا إلا إذا تمكنتم من ضمان أن المطبخ خالٍ من الغلوتين." يتحقق النادل من المطبخ ويعود قائلاً: "أنا آسف، لا يمكننا تلبية هذا الشرط." لم يتم طلب الوجبة حتى. هذا الفحص الأولي وفشله هو بالضبط ما يدور حوله رمز حالة HTTP **417 Expectation Failed**.

417 هو أحد الأعضاء الأقل شهرة في عائلة رموز حالة HTTP. إنه لا يتعامل مع الصفحات المفقودة، أو مشكلات المصادقة، أو أخطاء الخادم. بدلاً من ذلك، يتعامل مع نوع محدد جدًا من التفاوض الفاشل بين العميل والخادم في بداية محادثتهما.

إنها طريقة الخادم للقول: "لقد وضعت شرطًا مسبقًا لا يمكنني تلبيته، لذا لن أحاول حتى معالجة طلبك الرئيسي."

إذا كنت مطورًا تعمل مع خوادم الويب أو تبني عملاء HTTP، فإن فهم هذا الرمز النادر يوفر نظرة ثاقبة رائعة لتصميم البروتوكول من أجل التواصل الفعال.

💡
إذا كنت تبني أو تختبر واجهات برمجة التطبيقات (APIs) وترغب في ضمان تواصل سلس بين العميل والخادم، فأنت بحاجة إلى أداة يمكنها التعامل مع جميع أنواع تفاعلات HTTP. **قم بتنزيل Apidog مجانًا**؛ إنها منصة API شاملة تساعدك على صياغة طلبات دقيقة وفهم استجابات الخادم، مما يسهل تصحيح الأخطاء حتى في أكثر رموز الحالة غموضًا.
زر

لفهم كيفية حدوث ذلك، ولماذا يهم، وماذا تفعل حياله بشكل كامل، دعنا نمر بالتفاصيل خطوة بخطوة.

المشكلة: إهدار النطاق الترددي على الطلبات المحكوم عليها بالفشل

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

  1. العميل: (يرسل ملفًا بحجم 100 ميجابايت) "هذه بياناتي!"
  2. الخادم: (بعد استلام الملف بأكمله) "آسف، الملف كبير جدًا. لا يمكنني قبول ملفات تتجاوز 50 ميجابايت."
  3. النتيجة: إهدار 100 ميجابايت من النطاق الترددي لطلب كان محكومًا عليه بالفشل منذ البداية.

تم تصميم رأس Expect ورمز الحالة 417 لمنع هذا النوع من السيناريوهات المهدرة بالضبط.

ماذا يعني رمز HTTP 417 "Expectation Failed" فعليًا؟

يشير رمز الحالة 417 Expectation Failed إلى أن الخادم لا يمكنه تلبية متطلبات حقل رأس طلب Expect. في الأساس، قال العميل: "أتوقع منك أن تكون قادرًا على فعل X"، ويرد الخادم: "لا يمكنني فعل X، لذا لن أقوم بمعالجة طلبك."

القيمة الأكثر شيوعًا، ولفترة طويلة، القيمة الوحيدة لرأس Expect كانت 100-continue.

تبدو استجابة 417 النموذجية كالتالي:

HTTP/1.1 417 Expectation FailedContent-Type: text/htmlContent-Length: 125
<html><head><title>417 Expectation Failed</title></head><body><center><h1>417 Expectation Failed</h1></center></body></html>

بالنسبة لواجهات برمجة التطبيقات (APIs)، قد تتضمن نص JSON أكثر فائدة:

HTTP/1.1 417 Expectation FailedContent-Type: application/json
{
  "error": "ExpectationFailed",
  "message": "Server does not support the Expect header condition",
  "code": 417
}

مصافحة Expect: 100-continue

لفهم 417 حقًا، نحتاج إلى فحص الاستخدام الأكثر شهرة لرأس Expect: Expect: 100-continue. هذا يخلق عملية طلب من خطوتين مصممة لمنع إهدار النطاق الترددي.

السيناريو المتفائل (النجاح)

العميل يرسل الرؤوس: يرسل العميل رؤوس الطلب مع Expect: 100-continue، لكنه يحجب نص الطلب.

POST /upload HTTP/1.1Host: example.comContent-Type: application/octet-streamContent-Length: 104857600  # 100MBExpect: 100-continue

(لاحظ أنه لا يوجد نص بعد)

استجابة الخادم 100 Continue: يتحقق الخادم مما إذا كان يمكنه معالجة الطلب (على سبيل المثال، لديه مساحة، يقبل نوع المحتوى). إذا كان الأمر كذلك، فإنه يستجيب:

HTTP/1.1 100 Continue

العميل يرسل النص: يستقبل العميل 100 Continue ويرسل الآن نص ملف 100 ميجابايت.

الاستجابة النهائية للخادم: يعالج الخادم الطلب الكامل ويستجيب بالحالة النهائية (على سبيل المثال، 201 Created).

سيناريو 417 (الفشل)

العميل يرسل الرؤوس: نفس الطلب الأولي مع Expect: 100-continue.

استجابة الخادم 417: يحدد الخادم أنه لا يمكنه تلبية التوقع (على سبيل المثال، الملف كبير جدًا، نوع محتوى غير مدعوم).

HTTP/1.1 417 Expectation FailedContent-Type: application/json
{"error": "File size exceeds 50MB limit"}

العميل يتوقف: لا يرسل العميل أبدًا نص 100 ميجابايت، مما يوفر نطاقًا تردديًا ووقتًا كبيرين.

لماذا يحدث خطأ 417 "Expectation Failed"؟

دعنا نكشف الطبقات. السبب الرئيسي لـ 417 هو استخدام **رأس طلب Expect**، وخاصة Expect: 100-continue. تسمح مواصفات HTTP/1.1 للعملاء بإرسال هذا الرأس لتقليل نقل البيانات غير الضروري. إليك كيفية عمله نظريًا:

  1. يرسل العميل طلبًا برؤوس **تتضمن** Expect: 100-continue، ولكن *لا يوجد نص بعد*.
  2. يفحص الخادم الرؤوس. إذا كان الخادم موافقًا على استلام النص (بناءً على أشياء مثل الرؤوس، المصادقة، الطريقة)، فيجب أن يستجيب بحالة **100 Continue**، أي "نعم، تفضل، أرسل نصك."
  3. ثم يرسل العميل نص الطلب الفعلي (مثل تحميل ملف أو حمولة JSON كبيرة).
  4. يكمل الخادم المعالجة ويعيد الاستجابة النهائية (مثل 200، 201، إلخ).

ومع ذلك، في بعض الأحيان تسوء الأمور:

عندما يحدث ذلك، بدلاً من إرسال 100 Continue، يمكن للخادم الاستجابة بـ **417 Expectation Failed**، ليخبر العميل "لا يمكنني الامتثال لذلك التوقع الذي طلبته."

وفقًا لوثائق MDN:

يشير رمز حالة استجابة خطأ العميل HTTP 417 Expectation Failed إلى أنه لا يمكن تلبية التوقع المحدد في رأس طلب Expect. وثائق الويب MDN
Expect

تردد مصادر أخرى هذا: ينشأ خطأ 417 عندما لا يدعم الخادم التوقعات (أو هذا التوقع المحدد) ولكن العميل أدرج واحدًا على أي حال.

لذا، عادة لا يتعلق الأمر بـ "حمولة بياناتك خاطئة"، بل بـ "رأس التوقع الخاص بك غير مقبول."

لماذا ترفض بعض الخوادم التوقع

لا تدعم جميع الخوادم أو الوسطاء مصافحة التوقع هذه. تتضمن بعض الأسباب ما يلي:

إذا لم يتمكن الخادم أو لم يستجب بـ 100 Continue، ولكن العميل يتوقع ذلك (أي أن رأس Expect موجود)، فإن هذا عدم التطابق يؤدي إلى **417 Expectation Failed**.

لهذا السبب، غالبًا ما يكون الحل بسيطًا: **لا ترسل Expect**  أو قم بإزالته عندما يكون التوافق محل شك.

لماذا نادرًا ما ترى 417 في الواقع

على الرغم من كونها فكرة ذكية، فإن رمز الحالة 417 نادر للغاية اليوم. إليك السبب:

1. دعم الخادم غير المتناسق

لم تقم العديد من خوادم الويب وأطر عمل التطبيقات بتنفيذ دعم مناسب لمصافحة Expect: 100-continue. عندما يتلقون هذا الرأس، غالبًا ما يتجاهلونه ويعالجون الطلب بشكل طبيعي، أو يعيدون خطأ مثل 400 Bad Request.

2. تعقيد جانب العميل

يضيف تنفيذ المصافحة ذات الخطوتين تعقيدًا إلى عملاء HTTP. يحتاجون إلى:

قامت العديد من مكتبات العميل بتبسيط تنفيذها بعدم استخدام Expect: 100-continue على الإطلاق.

3. صعود الشبكات الأسرع

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

4. الأساليب البديلة

وجد المطورون طرقًا أخرى لحل نفس المشكلة:

تشريح استجابة 417

عندما يعيد الخادم **417 Expectation Failed**، كيف تبدو الاستجابة؟ دعنا نلقي نظرة على العناصر النموذجية:

سطر الحالة:

HTTP/1.1 417 Expectation Failed

الرؤوس:

قد تتضمن Content-Type، Content-Length، وربما نصًا يوضح الفشل (HTML أو JSON).

عادة *لا* تتضمن 100 Continue لأنها استجابة نهائية ترفض التوقع.

قد تتضمن أيضًا رؤوس الخادم أو التشخيص (مثل Server، Date).

النص (اختياري):

غالبًا ما تكون صفحة خطأ بسيطة أو نص JSON يخبر العميل بأن التوقع قد فشل.

مثال (مبسط):

HTTP/1.1 417 Expectation Failed
Content-Type: text/plain
Content-Length: 25

Expectation not supported

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

سيناريوهات شائعة متى وأين سترى 417

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

السيناريو 1: تحميل ملف أو طلب API من نوع PUT/POST مع Expect: 100-continue

أنت تقوم بتحميل ملف أو إرسال JSON كبير عبر PUT أو POST، ويقوم عميل HTTP الخاص بك أو إطار العمل بإضافة Expect: 100-continue تلقائيًا. لا يدعم الخادم تلك المصافحة، لذلك يعيد 417. غالبًا ما يرى العملاء هذا عند إجراء مكالمات HTTP من .NET، Java، إلخ.

على سبيل المثال، تشير بعض مواضيع StackOverflow إلى أن `HttpWebRequest` في .NET يضبط `Expect: 100-continue` افتراضيًا، وإذا رفضه الخادم، فسترى 417.

السيناريو 2: تداخل الوكيل أو البرمجيات الوسيطة

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

السيناريو 3: خادم أو بوابة API خاطئة التكوين

خادمك (أو بوابة API أمامه) تم تكوينه بشكل خاطئ فيما يتعلق بدعم التوقع. على سبيل المثال، قد يرفض `Expect` صراحةً أو يفتقر إلى المنطق لتحليله. في بعض الأحيان، تستجيب مسارات التعليمات البرمجية في الخادم للرؤوس غير المتوقعة بأخطاء عامة مثل 417.

السيناريو 4: استخدام المكتبات أو الإعدادات الافتراضية لإطار العمل

تضيف بعض أطر العمل أو حزم تطوير البرمجيات (SDKs) `Expect` افتراضيًا. إذا كان خادمك لا يدعم ذلك، فسترى 417. في بعض بيئات .NET، يقوم الأشخاص بتعيين `ServicePointManager.Expect100Continue = false` لتعطيل السلوك الافتراضي.

السيناريو 5: أدوات الاختبار أو عملاء HTTP

قد تختبر باستخدام Postman أو cURL أو Apidog. إذا قمت بتعيين رأس `Expect` بشكل صريح (أو إذا قامت الأداة بذلك تلقائيًا)، فقد تتلقى 417 عند الاختبار، حتى لو لم تقم بتضمين هذا الرأس في الاستخدام الفعلي.

الاستخدامات الحديثة وعودة الظهور

على الرغم من ندرته، يجد رأس Expect وحالة 417 حياة جديدة في سياقات محددة:

1. تحديد معدل واجهة برمجة التطبيقات (API Rate Limiting)

تستخدم بعض واجهات برمجة التطبيقات فحوصات توقع مخصصة:

GET /api/data HTTP/1.1Expect: ratelimit=1000

إذا تجاوز العميل حد معدله، يمكن للخادم الاستجابة بـ 417 Expectation Failed بدلاً من معالجة الطلب ثم إرجاع 429 Too Many Requests.

2. التفاوض على الميزات

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

POST /api/process HTTP/1.1Expect: features=ml-prediction,image-recognition

إذا كان الخادم لا يدعم هذه الميزات، فيمكنه إرجاع 417 مع تفاصيل حول ما يمكنه دعمه.

3. التحقق من صحة الموارد

التحقق مما إذا كانت الموارد المطلوبة متاحة قبل معالجة طلب معقد.

اختبار تدفقات Expect/Continue باستخدام Apidog

يعد اختبار مصافحة Expect: 100-continue يدويًا أمرًا صعبًا للغاية، وهو سبب آخر لندرة استخدامه. **Apidog** يجعل هذه العملية أكثر سهولة في الإدارة.

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

  1. صياغة رؤوس Expect: أضف بسهولة Expect: 100-continue أو رؤوس توقع مخصصة إلى طلباتك.
  2. محاكاة العملية ذات الخطوتين: يمكن لـ Apidog التعامل مع الطلب الأولي الذي يحتوي على الرؤوس فقط والانتظار لاستجابة الخادم المؤقتة.
  3. اختبار توافق الخادم: تحقق مما إذا كان خادمك يطبق مصافحة Expect/Continue بشكل صحيح عن طريق التحقق مما إذا كان يعيد 100 Continue، 417 Expectation Failed، أو يتجاهل الرأس تمامًا.
  4. تصحيح الأخطاء في التوقعات المخصصة: إذا كنت تنفذ منطق توقع مخصصًا في واجهة برمجة التطبيقات الخاصة بك، فاستخدم Apidog لاختبار سيناريوهات مختلفة والتأكد من أن استجابات 417 تتضمن معلومات خطأ مفيدة.
  5. مقارنة الأساليب: اختبر نفس التحميل مع وبدون Expect: 100-continue لترى اختلافات الأداء في حالة الاستخدام الخاصة بك.
زر

من خلال التكرار بهذه الطريقة، يمنحك Apidog ملاحظات سريعة أثناء تعديل سلوك العميل أو الخادم.

كيفية إصلاح أو تجنب أخطاء 417

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

إزالة أو تعطيل رأس Expect من جانب العميل

إذا أمكن، لا ترسل Expect: 100-continue على الإطلاق. تسمح العديد من العملاء بتبديل هذا:

بإرسال طلب مباشر، تتجنب إطلاق مصافحة التوقع بالكامل.

تكوين الخادم لقبول التوقعات

إذا كنت تتحكم في الخادم، يمكنك محاولة دعم مصافحة Expect:

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

استخدام منطق الاحتياطي

إذا تلقيت 417، يجب أن يقوم منطق العميل الخاص بك بما يلي:

  1. التقاط استجابة 417
  2. إعادة محاولة نفس الطلب بالضبط *بدون* رأس Expect وإرسال النص على الفور
  3. المتابعة بمعالجة الاستجابة

هذا يضمن أنه حتى إذا فشلت دلالات التوقع، فإن طلبك لا يزال يمر.

مراجعة البرمجيات الوسيطة، الوكلاء والبوابات

تأكد من أن أي من الوسطاء (الوكلاء، موازنات التحميل، البوابات) لا يجرد أو يسيء تفسير رأس Expect. إذا فعلوا ذلك، فقد تحتاج إلى تعديلات في التكوين أو ترقيات للإصدار.

ضع إصدارات HTTP والمواصفات في الاعتبار

تأكد من أن خادم HTTP الخاص بك وأي وكلاء يدعمون ميزات HTTP/1.1 بشكل صحيح. تأكد من أن بنيتك التحتية لا تقوم بتخفيض أو سوء تفسير رؤوس الطلبات.

توثيق السلوك وعقود API

في وثائق واجهة برمجة التطبيقات الخاصة بك، لاحظ ما إذا كانت رؤوس Expect مدعومة أم لا، وأوصِ العملاء بعدم إرسالها (إذا كنت لا تدعمها). تقلل الوثائق الواضحة من الارتباك وأخطاء العميل.

مراقبة والتنبيه على 417

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

أفضل الممارسات للتطوير الحديث

إذا كنت تبني خادمًا:

إذا كنت تبني عميلاً:

لمعظم التطبيقات:

المزالق الشائعة، المفاهيم الخاطئة والنصائح

إليك بعض الأخطاء والتوضيحات التي يجب الانتباه إليها:

  1. مفهوم خاطئ: 417 يعني أن النص خاطئ: لا، 417 يتعلق بالتوقعات (الرؤوس)، وليس بمحتوى الحمولة.
  2. سوء استخدام 417 لأخطاء التحقق من الصحة: لا تستخدم 417 عندما يفشل مخطط JSON أو يفشل التحقق من الصحة. استخدم 400، 422، أو رموز 4xx المناسبة بدلاً من ذلك.
  3. افتراض أن جميع الخوادم تدعم Expect: العديد من الخوادم، الوكلاء، أو طبقات CDN لا تدعمها. لا تعتمد على دلالات التوقع إلا إذا كنت تتحكم في المكدس الكامل.
  4. تجاهل الوكلاء والبرمجيات الوسيطة: حتى لو كان خادمك الأصلي يدعم `Expect`، فإن البنية التحتية الأولية قد تفسده.
  5. إهمال منطق الاحتياطي: خطط دائمًا للعملاء لإعادة المحاولة بدون `Expect`.
  6. الإزالة العشوائية لـ `Expect` في كل مكان: إذا كانت بعض الخوادم تدعم `Expect` وتساعد المصافحة (على سبيل المثال في قبول الحمولة الكبيرة المشروط)، فإن إزالته عالميًا قد يقلل الكفاءة. استخدمه بحكمة.
  7. نقص التوثيق: إذا لم توثق واجهة برمجة التطبيقات الخاصة بك دعم التوقع (أو عدمه)، فقد يشعر مطورو العميل بالارتباك عندما تظهر أخطاء 417.
  8. عدم مراقبة معدلات 417: إذا كان عميل واحد أو تكامل واحد يثير العديد من أخطاء 417، فقد يخفي ذلك خطأ أعمق في كيفية تشكيلهم للطلبات.

لماذا يهم فهم 417 في الأنظمة الواقعية

قد تعتقد أن 417 نادر، فلماذا تهتم؟ ولكن هناك أسباب وجيهة:

  1. قابلية تشغيل أفضل: قد يتم استهلاك واجهة برمجة التطبيقات الخاصة بك من قبل العديد من العملاء (تطبيقات الطرف الثالث، حزم تطوير برمجيات الجوال). إذا استخدم بعضهم `Expect` ورفضتهم، فسيفشلون ما لم تتعامل مع الأمر بلطف.
  2. معالجة فعالة للحمولات الكبيرة: تهدف مصافحة `Expect: 100-continue` إلى تجنب إرسال نصوص كبيرة عندما يرفضها الخادم. إذا دعمته بشكل صحيح، يمكن أن يوفر ذلك النطاق الترددي وزمن الاستجابة.
  3. معالجة الأخطاء وتصحيحها بشفافية: يخبرك 417 بدقة *لماذا* رفض الخادم الطلب (عدم تطابق التوقع). وهذا أكثر إفادة من "خطأ داخلي 500" الغامض.
  4. موثوقية الإنتاج: في الحالات الهامشية (مثل تحميلات الملفات الكبيرة، سلاسل الوكلاء، التحديثات التدريجية)، قد يفشل منطق التوقع بشكل غير متوقع. معرفة كيفية تحديد 417 وتخفيفه يساعد في منع الأخطاء الصامتة.
  5. تأثيرات تحسين محركات البحث والفهرسة: على الرغم من أن 417 هو خطأ من جانب العميل، إذا واجهت برامج الزحف أو أدوات المراقبة 417 على نقاط نهاية مهمة، فقد تصبح صفحات النتائج غير مفهرسة أو معلمة. تشير إحدى المقالات إلى أن استجابات 417 قد تؤدي إلى إسقاط محركات الزحف للصفحات.
  6. تجربة المطور: العملاء الذين يرون 417 سيشخصون بسهولة أكبر "عدم تطابق توقع الرأس" إذا كانت رسائل الخطأ والاحتياطي الخاصة بك واضحة.

العلاقة مع رموز الحالة الأخرى

من المفيد فهم كيفية ارتباط 417 برموز أخطاء العميل الأخرى:

الخلاصة: حل متخصص ينتظر لحظته

يمثل رمز حالة HTTP 417 Expectation Failed تحسينًا ذكيًا لم يحقق انتشارًا واسعًا أبدًا. إنه حل لمشكلة حقيقية تمنع إهدار النطاق الترددي على الطلبات المحكوم عليها بالفشل، والتي تم تجاوزها في النهاية بالتقدم التكنولوجي والأساليب البديلة.

ومع ذلك، فإنه لا يزال موجودًا في مواصفات HTTP، وهو دليل على التصميم الشامل للبروتوكول. بالنسبة لتطبيقات متخصصة معينة - خاصة تلك التي تتضمن نقل بيانات كبيرة عبر شبكات محدودة - لا يزال بإمكان مصافحة Expect/Continue وإشارة فشلها 417 توفير كفاءة قيمة.

يمنحك فهم 417 نظرة أعمق في فلسفة تصميم HTTP والتطور المستمر لمعايير الويب. بينما قد لا تحتاج أبدًا إلى تنفيذه بنفسك، فإن معرفة وجوده يجعلك مطور ويب أكثر دراية.

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

زر

ممارسة تصميم API في Apidog

اكتشف طريقة أسهل لبناء واستخدام واجهات برمجة التطبيقات

التسجيل مجانًاتحميل