مشغّلو الخدمات من مصادر خارجية: تجربة الجلب من مصادر خارجية

Jeff Posnick

تحذير: المعلومات الواردة في هذه المشاركة قديمة. لم يعُد الإجراء fetchForeign متاحًا للاختبار في Chrome، وتمت إزالته من مواصفات موظّف الخدمة.

الخلفية

تمنح خدمات العمال لمطوّري الويب إمكانية الاستجابة لطلبات الشبكة التي تقدّمها تطبيقات الويب، ما يسمح لهم بمواصلة العمل حتى في حال عدم الاتصال بالإنترنت، ومكافحة شبكة Wi-Fi غير الموثوق بها، وتنفيذ تفاعلات معقدة مع ذاكرة التخزين المؤقت، مثل stale-while-revalidate. ولكنّ مشغّلات الخدمات كانت مرتبطة في السابق بمصدر معيّن. وبصفتك مالك تطبيق ويب، تقع على عاتقك مسؤولية كتابة مشغّل خدمات ونشره للاعتراض على جميع طلبات الشبكة التي يقدّمها تطبيق الويب. في هذا النموذج، يتحمّل كل عامل خدمة مسؤولية معالجة الطلبات من مصادر متعددة، مثل واجهة برمجة تطبيقات تابعة لجهة خارجية أو خطوط ويب.

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

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

• مزوّدو واجهات برمجة التطبيقات الذين يستخدمون واجهات RESTful
• موفّرو خطوط الويب
• مقدّمو خدمة الإحصاءات
• موفِّرو استضافة الصور
• شبكات توصيل المحتوى العامة

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

المتطلبات الأساسية

الرمز المميّز الخاص بالفترة التجريبية

لا تزال ميزة "الاسترجاع من مصدر خارجي" تجريبية. ولتجنّب طرح هذا التصميم قبل الأوان قبل أن يتم تحديده بالكامل والاتفاق عليه من قِبل مورّدي المتصفّحات، تم تنفيذه في الإصدار 54 من Chrome كإصدار تجريبي. ما دامت ميزة "الجلب من الخارج" لا تزال في مرحلة تجريبية، لاستخدام هذه الميزة الجديدة مع الخدمة التي تستضيفها، سيكون عليك طلب رمز مميّز مخصّص للوصول إلى المصدر المحدَّد لخدمتك. يجب تضمين الرمز المميّز كعنوان استجابة HTTP في جميع طلبات الموارد من مصادر متعددة التي تريد التعامل معها من خلال ميزة "الاسترداد من مصدر خارجي"، بالإضافة إلى الاستجابة لمورد JavaScript الخاص بعامل الخدمة:

Origin-Trial: token_obtained_from_signup

ستنتهي الفترة التجريبية في آذار (مارس) 2017. نتوقع أن ننتهي من إجراء أي تغييرات ضرورية لتحسين أداء الميزة، ونأمل أن نتمكّن من تفعيلها تلقائيًا. إذا لم يتم تفعيل ميزة "الاسترداد من مصدر خارجي" تلقائيًا بحلول ذلك الوقت، سيتوقّف عمل الوظيفة المرتبطة برموز Origin Trial المتوفّرة حاليًا.

لتسهيل تجربة الجلب الخارجي قبل التسجيل للحصول على رمز مميّز رسمي للإصدار التجريبي Origin، يمكنك تجاوز المتطلبات في Chrome لجهاز الكمبيوتر المحلي من خلال الانتقال إلى chrome://flags/#enable-experimental-web-platform-features وتفعيل علامة "الميزات التجريبية للنظام الأساسي للويب". يُرجى العِلم أنّه يجب إجراء ذلك في كل مثيل من متصفّح Chrome الذي تريد استخدامه في تجاربك المحلية، في حين أنّ الميزة ستكون متاحة لجميع مستخدمي Chrome باستخدام رمز مميّز لإصدار أوّلي.

HTTPS

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

استخدام ميزة "الاسترداد من مصدر خارجي"

بعد الانتهاء من المتطلبات الأساسية، لنلقِ نظرة على التفاصيل الفنية اللازمة لبدء تشغيل عامل خدمة جلب خارجي.

تسجيل مشغّل الخدمة

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

// You can't do this!
if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('service-worker.js');
}

يكون رمز JavaScript هذا لتسجيل عامل خدمة تابع للطرف الأول منطقيًا في سياق تطبيق ويب يتم تشغيله من قِبل مستخدم ينتقل إلى عنوان URL تتحكم فيه. ولكنّ هذا النهج غير مناسب لتسجيل عامل خدمة تابع لجهة خارجية، لأنّ التفاعل الوحيد الذي سيجريه المتصفّح مع خادمك هو طلب مورد فرعي معيّن، وليس التنقّل الكامل. إذا طلب المتصفح، على سبيل المثال، صورة من خادم شبكة توصيل المحتوى (CDN) الذي تحتفظ به، لا يمكنك إضافة مقتطف JavaScript هذا إلى استجابتك وتوقع تشغيله. يجب استخدام طريقة مختلفة لتسجيل عامل الخدمة خارج سياق تنفيذ JavaScript العادي.

يتم تقديم الحلّ على شكل عنوان HTTP يمكن أن يتضمّنه خادمك في أي استجابة:

Link: </service-worker.js>; rel="serviceworker"; scope="/"

لنقسّم مثال العنوان هذا إلى مكوّناته، مع الفصل بين كل مكوّن بحرف ;.

• يجب إدخال </service-worker.js>، ويتم استخدامه لتحديد مسار ملف worker الخدمة (استبدِل /service-worker.js بالمسار المناسب لملف النص البرمجي). يتوافق ذلك مباشرةً مع سلسلة scriptURL التي سيتم تمريرها كأول مَعلمة إلى navigator.serviceWorker.register(). يجب أن تكون القيمة محاطة بعلامات <> (على النحو المطلوب في مواصفات رأس Link)، وإذا تم تقديم عنوان URL نسبي بدلاً من عنوان URL مطلق، سيتم تفسيره على أنّه نسبي إلى الموقع الجغرافي للاستجابة.
• يجب أيضًا إدراج السمة rel="serviceworker"، ويجب تضمينها بدون الحاجة إلى إجراء أي تخصيص.
• scope=/ هو إعلان نطاق اختياري، يكافئ سلسلة options.scope ويمكنك تمريره كمَعلمة ثانية إلى navigator.serviceWorker.register(). في العديد من حالات الاستخدام، لا بأس باستخدام النطاق التلقائي، لذا يمكنك عدم تضمين هذا الحقل ما لم تكن بحاجة إليه. تنطبق القيود نفسها حول الحد الأقصى المسموح به للنطاق، بالإضافة إلى إمكانية تخفيف هذه القيود من خلال عنوان Service-Worker-Allowed، على عمليات تسجيل عنوان Link.

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

تذكَّر أنّ ميزة "الاسترداد من مصدر خارجي" يتم تنفيذها حاليًا كجزء من الإصدار التجريبي من الإصدار الأصلي، لذا عليك تضمين عنوان Origin-Trial صالح أيضًا إلى جانب عنوان استجابة الرابط. الحد الأدنى لمجموعة رؤوس الاستجابة المراد إضافتها لتسجيل عامل خدمة الجلب الخارجي هو

Link: </service-worker.js>; rel="serviceworker"
Origin-Trial: token_obtained_from_signup

ملاحظة: قد لاحظ القرّاء المُدقّقون لمواصفات موظّف الخدمة وسيلة أخرى لإجراء تسجيل موظّف الخدمة، وذلك من خلال عنصر <link rel="serviceworker"> DOM. يتم حاليًا التحكّم في إتاحة التسجيل المستنِد إلى <link> في Chrome من خلال إصدار Origin Trial نفسه المستخدَم في عنوان Link، لذا لم يتم تفعيله تلقائيًا بعد. يواجه التسجيل المستنِد إلى <link> القيود نفسها التي يواجهها التسجيل المستنِد إلى JavaScript في ما يتعلق بتسجيل الجلب الأجنبي، لذا لأغراض هذه المقالة، يجب استخدام العنوان Link.

تسجيل تصحيح الأخطاء

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

هل يتم إرسال رؤوس الاستجابة الصحيحة؟

لتسجيل عامل خدمة الجلب الخارجي، عليك ضبط رأس Link في استجابة لمورد مستضاف على نطاقك، كما هو موضّح سابقًا في هذه المشاركة. خلال فترة "الإصدار التجريبي من المصدر"، وافترضنا أنّه لم يتم ضبط chrome://flags/#enable-experimental-web-platform-features، عليك أيضًا ضبط عنوان استجابة Origin-Trial. يمكنك التأكّد من أنّ خادم الويب يضبط هذه العناوين من خلال الاطّلاع على الإدخال في لوحة الشبكة في "أدوات مطوّري البرامج":

هل تم تسجيل مشغّل خدمات "الاسترداد من المواقع الخارجية" بشكلٍ صحيح؟

يمكنك أيضًا تأكيد تسجيل عامل الخدمة الأساسي، بما في ذلك نطاقه، من خلال الاطّلاع على القائمة الكاملة لعمال الخدمة في لوحة التطبيق في "أدوات المطوّر". تأكَّد من تحديد الخيار "عرض الكل"، لأنّه سيظهر لك تلقائيًا مشغّلي الخدمات للمصدر الحالي فقط.

معالِج حدث التثبيت

الآن بعد أن سجّلت مشغّل الخدمات التابع لجهة خارجية، سيحصل على فرصة للردّ على حدثَي install وactivate، تمامًا كما يفعل أيّ مشغّل خدمات آخر. ويمكن أن يستفيد من هذه الأحداث مثلاً لتعبئة ذاكرات التخزين المؤقت بالموارد المطلوبة أثناء حدث install أو إزالة ذاكرات التخزين المؤقت القديمة في الحدث activate.

بالإضافة إلى الأنشطة العادية لتخزين أحداث install في ذاكرة التخزين المؤقت، هناك خطوة إضافية مطلوب تنفيذها داخل معالِج أحداث install الخاص بعامل الخدمة التابع لجهة خارجية. يجب أن تستدعي رمزك registerForeignFetch()، كما هو موضّح في المثال التالي:

self.addEventListener('install', event => {
    event.registerForeignFetch({
    scopes: [self.registration.scope], // or some sub-scope
    origins: ['*'] // or ['https://example.com']
    });
});

هناك خياران للضبط، وكلاهما مطلوب:

• تأخذ دالة scopes صفيفًا من سلسلة واحدة أو أكثر، يمثّل كلّ منها نطاقًا للطلبات التي ستؤدي إلى تشغيل حدث foreignfetch. ولكن انتظر قد يكون مضمونك لقد سبق أن حدّدت نطاقًا أثناء تسجيل مشغّلي الخدمات. هذا صحيح، وأن النطاق الإجمالي لا يزال ذا صلة، فكل نطاق تحدده هنا يجب أن يكون إما مساويًا للنطاق الكلي لمشغِّل الخدمات أو نطاقًا فرعيًا له. تسمح لك قيود النطاق الإضافية هنا بنشر مشغّل خدمات لجميع الأغراض يمكنه التعامل مع أحداث fetch للطرف الأول (للطلبات التي يتم إجراؤها من موقعك الإلكتروني) وأحداث foreignfetch التابعة لجهة خارجية (للطلبات التي يتم تقديمها من نطاقات أخرى)، وتوضيح أنّه يجب تشغيل foreignfetch ضمن مجموعة فرعية فقط من نطاقك الأكبر. من الناحية العملية، إذا كنت بصدد نشر عامل خدمة مخصّص للتعامل مع أحداث foreignfetch التابعة لجهات خارجية فقط، ستحتاج إلى استخدام نطاق واحد وواضح يساوي النطاق العام لعامل الخدمة. وهذا ما سيفعله المثال أعلاه باستخدام القيمة self.registration.scope.
• يقبل origins أيضًا صفيفًا من سلسلة واحدة أو أكثر، ويسمح لك بحصر معالِج foreignfetch بالردّ على الطلبات الواردة من نطاقات معيّنة فقط. على سبيل المثال، إذا سمحت صراحةً بـ "https://example.com"، سيؤدي طلب مُرسَل من صفحة مستضافة على https://example.com/path/to/page.html لمورد معروض من نطاق الجلب الخارجي إلى تنشيط معالِج الجلب الخارجي، ولكن لن يؤدي الطلبات المُرسَلة من https://random-domain.com/path/to/page.html إلى تنشيط المعالِج. ما لم يكن لديك سبب محدّد لتشغيل منطق الجلب الخارجي لمجموعة فرعية فقط من مصادر البيانات البعيدة، يمكنك ببساطة تحديد '*' كقيمة وحيدة في الصفيف، وسيتم السماح بجميع مصادر البيانات.

معالج حدث foreignfetch

بعد تثبيت خدمة عامل التشغيل التابع لجهة خارجية وضبطه من خلال registerForeignFetch()، ستتوفّر له فرصة اعتراض طلبات الموارد الفرعية من مصادر مختلفة إلى خادمك التي تندرج ضمن نطاق الجلب الخارجي.

ملاحظة: هناك قيد إضافي في عملية التنفيذ الحالية في Chrome: طلبات GET أو POST أو HEAD التي تحتوي فقط على عناوين ضمن القائمة الآمنة CORS مؤهّلة للجلب الخارجي. لا يشكّل هذا التقييد جزءًا من مواصفات الجلب الخارجي، وقد يتم تخفيف قيوده في الإصدارات المستقبلية من Chrome.

في الخدمة التقليدية التي يوفّرها الطرف الأول، يؤدي كل طلب إلى بدء حدث fetch يمكن لعامل الخدمة الردّ عليه. يتم منح عامل الخدمة التابع لجهة خارجية فرصة معالجة حدث مختلف قليلاً، يُسمى foreignfetch. من الناحية المفهومية، يتشابه الحدثان تمامًا، ويمنحانك الفرصة لفحص الطلب الوافد، وتقديم ردّ عليه اختياريًا من خلال respondWith():

self.addEventListener('foreignfetch', event => {
    // Assume that requestLogic() is a custom function that takes
    // a Request and returns a Promise which resolves with a Response.
    event.respondWith(
    requestLogic(event.request).then(response => {
        return {
        response: response,
        // Omit to origin to return an opaque response.
        // With this set, the client will receive a CORS response.
        origin: event.origin,
        // Omit headers unless you need additional header filtering.
        // With this set, only Content-Type will be exposed.
        headers: ['Content-Type']
        };
    })
    );
});

على الرغم من أوجه التشابه في المفهوم، هناك بعض الاختلافات في الممارسة عند الاتصال respondWith() على ForeignFetchEvent. فبدلاً من توفير Response (أو Promise الذي يتطابق مع Response) إلى respondWith()، مثلما تفعل مع FetchEvent، عليك ضبط Promise الذي يعالج كائنًا له خصائص معيّنة إلى respondWith() الخاصة بـ ForeignFetchEvent:

• يجب إدخال قيمة response، ويجب ضبطها على عنصر Response الذي سيتم إرجاعه إلى العميل الذي قدّم الطلب. إذا قدّمت أي قيمة غير Response صالحة، سيتم إنهاء طلب العميل بظهور خطأ في الشبكة. على عكس استدعاء respondWith() داخل معالج حدث fetch، يجب تقديم Response هنا، وليس Promise الذي يتم حلّه باستخدام Response. يمكنك إنشاء استجابتك من خلال سلسلة وعد، ويجب تمرير هذه السلسلة كمَعلمة إلى respondWith() في foreignfetch، ولكن يجب أن تنتهي السلسلة بعنصر يحتوي على سمة response التي تم ضبطها على عنصر Response. يمكنك الاطّلاع على عرض توضيحي لهذا الإجراء في نموذج الرمز أعلاه.
• ‫origin اختياري، ويتم استخدامه لتحديد ما إذا كان الردّ الذي يتم إرجاعه مبهمًا أم لا. في حال عدم تضمين هذه المعلومات، سيكون الردّ غير واضح، ولن يتمكّن العميل من الوصول إلا إلى جزء محدود من نص الردّ وعناوينه. إذا تم تقديم الطلب باستخدام mode: 'cors'، سيتم التعامل مع عرض استجابة مبهمة على أنّها خطأ. ومع ذلك، إذا حدّدت قيمة سلسلة تساوي مصدر العميل البعيد (يمكن الحصول عليها من خلال event.origin)، يعني ذلك أنّك توافق صراحةً على تقديم استجابة مفعَّلة بتنسيق CORS إلى العميل.
• يكون الخيار headers اختياريًا أيضًا، ولا يكون مفيدًا إلا إذا كنت تحدّد أيضًا origin وتُرسل استجابة CORS. سيتم تلقائيًا تضمين العناوين الواردة في قائمة عناوين الاستجابة المُدرَجة في القائمة الآمنة لبروتوكول مشاركة الموارد المشتركة (CORS) فقط في استجابتك. إذا كنت بحاجة إلى فلترة البيانات المعروضة بشكل أكبر، تأخذ الرؤوس قائمة بأسماء رؤوس واحدة أو أكثر، وستستخدمها كقائمة مسموح بها للرؤوس التي سيتم عرضها في الاستجابة. يتيح لك ذلك تفعيل بروتوكول مشاركة الموارد المشتركة المنشأ (CORS) مع مواصلة منع عرض عناوين الاستجابة الحسّاسة المحتملة مباشرةً على العميل البعيد.

يُرجى العلم بأنّه عند تشغيل معالج foreignfetch، يتمتع بإمكانية الوصول إلى كل بيانات الاعتماد والمرجع المحيط للمصدر الذي يستضيف مشغّل الخدمات. وبصفتك مطوِّرًا ينشر مشغّل خدمة يمكن تفعيل الجلب به، تقع على عاتقك مسؤولية التأكّد من عدم تسريب أي بيانات استجابة محمية لا تتوفّر بحكم بيانات الاعتماد هذه. إنّ طلب الموافقة على طلبات CORS هو خطوة واحدة للحدّ من التعرّض غير المقصود، ولكن بصفتك مطوّرًا، يمكنك إرسال طلبات fetch() بشكل صريح داخل معالِج foreignfetch لا يستخدم بيانات الاعتماد الضمنية من خلال:

self.addEventListener('foreignfetch', event => {
    // The new Request will have credentials omitted by default.
    const noCredentialsRequest = new Request(event.request.url);
    event.respondWith(
    // Replace with your own request logic as appropriate.
    fetch(noCredentialsRequest)
        .catch(() => caches.match(noCredentialsRequest))
        .then(response => ({response}))
    );
});

اعتبارات العميل

هناك بعض الاعتبارات الإضافية التي تؤثّر في كيفية تعامل عامل خدمة الجلب الأجنبي مع الطلبات المقدَّمة من عملاء خدمتك.

العملاء الذين لديهم عامل خدمة تابع للجهة الأولى

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

تحصل معالِجات fetch في عامل خدمة تابع للطرف الأول على الفرصة الأولى للردّ على جميع الطلبات التي يقدّمها تطبيق الويب، حتى إذا كان هناك عامل خدمة تابع لجهة خارجية تم تفعيل foreignfetch فيه بنطاق يغطي الطلب. ولكن لا يزال بإمكان العملاء الذين لديهم عاملي خدمة لدى الطرف الأول الاستفادة من عامل خدمة الجلب الأجنبي.

داخل مشغّل خدمة تابع للجهة الأولى، سيؤدي استخدام fetch() لاسترداد موارد من مصادر متعددة إلى تنشيط مشغّل خدمة جلب الموارد الخارجي المناسب. وهذا يعني أنّ الرمز البرمجي التالي يمكنه الاستفادة من معالِج foreignfetch:

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    // If event.request is under your foreign fetch service worker's
    // scope, this will trigger your foreignfetch handler.
    event.respondWith(fetch(event.request));
});

وبالمثل، إذا كانت هناك معالِجات جلب من الطرف الأول، لكنّها لا تستدعي event.respondWith() عند معالجة طلبات المصدر المتعدد المصادر، سينتقل الطلب تلقائيًا إلى معالج foreignfetch:

// Inside a client's first-party service-worker.js:
self.addEventListener('fetch', event => {
    if (event.request.mode === 'same-origin') {
    event.respondWith(localRequestLogic(event.request));
    }

    // Since event.respondWith() isn't called for cross-origin requests,
    // any foreignfetch handlers scoped to the request will get a chance
    // to provide a response.
});

إذا كان معالِج fetch تابع للجهة الأولى يستدعي event.respondWith() ولكنّه لا يستخدم fetch() لطلب مورد ضمن نطاق الجلب الخارجي، لن تحصل الخدمة الخارجية التي توفّر الجلب على فرصة لمعالجة الطلب.

العملاء الذين ليس لديهم عامل خدمة خاص بهم

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

وضع كل شيء معًا: حيث يبحث العملاء عن الرد

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

1. معالِج fetch لمشغّل خدمات تابع للطرف الأول (إذا كان متوفّرًا)
2. معالِج foreignfetch لمشغّل خدمات تابع لجهة خارجية (إذا كان متوفّرًا، وطلبات مصادر متعددة فقط)
3. ذاكرة التخزين المؤقت لبروتوكول HTTP في المتصفّح (إذا كانت هناك استجابة جديدة)
4. الشبكة

يبدأ المتصفّح من الأعلى، واستنادًا إلى تنفيذ عامل الخدمة، سيستمر المتصفّح في أسفل القائمة إلى أن يعثر على مصدر للاستجابة.

مزيد من المعلومات

• شرح عملية الجلب من مصدر خارجي
• نموذج الرمز البرمجي والعرض التوضيحي المباشر
• أداة تتبُّع مشاكل موظّفي الخدمة

البقاء على اطّلاع

إنّ تنفيذ Chrome لمرحلة تجربة وتقييم ميزة "الاسترداد من مصدر خارجي" عرضة للتغيير بينما نعالج الملاحظات الواردة من المطوّرين. سنحرص على تعديل هذا المنشور باستمرار من خلال التغييرات المضمّنة، وسنُشير إلى التغييرات المحدّدة أدناه عند حدوثها. سنشارك أيضًا معلومات عن التغييرات الرئيسية من خلال حساب Twitter @chromiumdev.