رؤوس HTTP المخصصة: اصطلاحات التسمية


1 Answers

السؤال يحمل إعادة قراءة. لا يُشبه السؤال الفعلي المطروح ببادئات البائعين في خصائص CSS ، حيث يكون التدقيق والتفكير المستقبلي حول دعم البائع والمعايير الرسمية مناسبًا. السؤال الفعلي المطلوب أكثر شيوعًا هو اختيار أسماء معلمات طلب بحث URL. لا ينبغي لأحد أن يهتم بما هم. لكن التباعد بين الأسماء المخصصة هو أمر صالح تمامًا - ومشترك وصحيح -.

الأساس المنطقي:
يتعلق الأمر بالاتفاقيات بين مطوري البرامج المخصصة للرؤوس المخصصة للتطبيقات - " البيانات ذات الصلة بحساباتهم " - والتي لا علاقة لها بالموردين أو هيئات المعايير أو البروتوكولات التي سيتم تنفيذها بواسطة أطراف ثالثة ، باستثناء أن المطور المعني تحتاج ببساطة إلى تجنب أسماء العناوين التي قد يكون لها استخدام آخر مقصود من قبل الخوادم أو الوكلاء أو العملاء. لهذا السبب ، تعتبر الأمثلة "X-Gzip / Gzip" و "X-Forwarded-For / Forwarded-For" موضوعية. السؤال المطروح هو حول الاصطلاحات في سياق واجهة برمجة تطبيقات خاصة ، تشبه اصطلاحات تسمية معلمات طلب البحث. إنها مسألة تفضيل وتباعد بين الأسماء ؛ مخاوف بشأن "X-ClientDataFoo" يجري دعمها من قبل أي وكيل أو بائع دون "X" هي في غير محلها بشكل واضح.

لا يوجد شيء خاص أو سحري حول البادئة "X-" ، ولكنه يساعد على توضيح أنه رأس مخصص. في الواقع ، تساعد RFC-6648 et al على تعزيز حالة استخدام البادئة "X-" ، لأن - كما يتخلى بائعو وحدات HTTP والخوادم عن البادئة - التطبيق الخاص ، API الخاص ، البيانات الشخصية - أصبحت آلية التمرير معزولة بشكل أفضل ضد اصطدامات مساحة الاسم مع العدد الصغير من أسماء العناوين المحجوزة الرسمية. ومع ذلك ، فإن تفضيلي الشخصي والتوصية الخاصة بي هي المضي قدمًا خطوة أخرى على سبيل المثال "X-ACME-ClientDataFoo" (إذا كانت شركة widget الخاصة بك هي "ACME").

IMHO لا تكون مواصفات IETF محددة بشكل كاف للإجابة على سؤال OP ، لأنها تفشل في التمييز بين حالات الاستخدام المختلفة تمامًا: (أ) الباعة الذين يقدمون ميزات جديدة قابلة للتطبيق عالميًا مثل "Forwarded-For" من ناحية ، مقابل (B) مطوري التطبيقات الذين يمررون سلاسل مخصصة للتطبيق إلى / من العميل والخادم. المواصفات تتعلق فقط مع السابق ، (أ). السؤال هنا هو ما إذا كانت هناك اتفاقيات لـ (ب). هناك. أنها تنطوي على تجميع المعلمات معا حسب الترتيب الأبجدي ، وفصلها عن العديد من العناوين ذات الصلة بالمعايير من النوع (A). استخدام بادئة "X-" أو "X-ACME-" ملائم وشرعي لـ (B) ، ولا يتعارض مع (A). وكلما توقف البائعون عن استخدام "X-" من أجل (A) ، كلما أصبحت البتات (B) الأكثر تميزًا نظيفة.

مثال:
إن Google (التي تحمل بعض الوزن في مختلف هيئات المعايير) هي - اعتبارًا من اليوم ، 20141102 في هذا التعديل الطفيف لإجابتي - التي تستخدم حاليًا "X-Mod-Pagespeed" للإشارة إلى إصدار وحدة Apache المشاركة في تحويل استجابة معينة. هل هناك من يقترح حقًا أن تستخدم Google "Mod-Pagespeed" ، بدون "X-" ، و / أو تطلب من IETF أن يبارك استخدامها؟

ملخص:
إذا كنت تستخدم رؤوس HTTP مخصصة (كبديل مناسب أحيانًا لملفات تعريف الارتباط) داخل تطبيقك لتمرير البيانات إلى / من خادمك ، فإن هذه الرؤوس ، بشكل صريح ، لا يقصد استخدامها في أي وقت خارج سياق تطبيقك ، التباعد بين الأسماء مع بادئة "X-" أو "X-FOO-" هي اتفاقية معقولة وشائعة.

Question

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

أيضا ، لا تتردد في نشر أي استخدام ذكي لهذه التي عثر عليها على شبكة الإنترنت ؛ نحن نحاول تنفيذ ذلك باستخدام أفضل ما يوجد هناك كهدف :)




يتم تعريف سجل اسم حقل رأس في RFC3864 ولا يوجد شيء خاص بـ "X-".

بقدر ما أستطيع أن أقول ، لا توجد مبادئ توجيهية للرؤوس الخاصة ؛ في شك ، تجنبها. أو إلقاء نظرة على إطار عمل امتداد HTTP ( RFC 2774 ).

سيكون من المثير للاهتمام فهم المزيد من حالة الاستخدام ؛ لماذا لا يمكن إضافة المعلومات إلى نص الرسالة؟




Related