طلب فرع كامل برمز لا يفتح إلا بعضه

الخلاصة

• أضافت مسودة فريق MoQ المؤرخة في 2 نوفمبر قاعدة لطلبات بادئة فضاء أسماء المسارات. تشمل عمليات PUBLISH_NAMESPACE وSUBSCRIBE_NAMESPACE وSUBSCRIBE_TRACKS كل فضاء يبدأ بتلك البادئة.
• لكي يُجيز الرمز الطلب كله، يجب أن تكون قاعدة مطابقة الفضاء MATCH_PREFIX وأن يغطي نمط الرمز البادئة المطلوبة. وتتطلب SUBSCRIBE_TRACKS مطابقة اسم المسار بـMATCH_PREFIX ونمط فارغ، لأنها قد تصل إلى أي مسار في الفرع.
• يجوز للوسيط قبول نطاق أضيق في نوعَي الاشتراك إذا حصر رسائل الأسماء والنشر الصادرة في الجزء المرخص. لم تمنح المسودة هذا الخيار لعملية PUBLISH_NAMESPACE.

صلاحية اليوم لا تتسع تلقائياً لما يُضاف غداً

يمكن عدّ المسارات الموجودة الآن، لكن طلب البادئة يصف فرعاً لا قائمة ثابتة. تنص المادة 3.3.3 الجديدة في مسودة Privacy Pass الخاصة بـMoQ على أن العمليات الثلاث تشمل كل فضاء أسماء يبدأ بالبادئة المختارة. قد يظهر مسار جديد تحتها لاحقاً، فيدخل من حيث شكل الطلب. نسخة يوليو لم تتضمن هذا الحكم الخاص بطلبات البادئة.

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

يمكن للوسيط اختيار طريق مختلف عند SUBSCRIBE_NAMESPACE أو SUBSCRIBE_TRACKS: يقبل الرمز الأضيق، ثم يضمن بقاء رسائل NAMESPACE وNAMESPACE_DONE وPUBLISH وPUBLISH_SKIPPED التي يرسلها ضمن الأسماء والمسارات المأذون بها. هنا يصبح الوسيط جهة تنفيذ للصلاحية في كل مخرج. وتستند رسائل PUBLISH الناتجة عن SUBSCRIBE_TRACKS إلى رمز طلب الاشتراك الأصلي؛ لا يُنسخ الرمز داخل كل رسالة. يحتاج سجل التدقيق إلى وصل المخرجات بقرار القبول والفلترة.

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