Trình chạy dịch vụ trên nhiều nguồn gốc – Thử nghiệm với tìm nạp nước ngoài

Jeff Posnick

Thông tin khái quát

Trình chạy dịch vụ cho phép nhà phát triển web phản hồi các yêu cầu mạng do ứng dụng web của họ đưa ra, cho phép họ tiếp tục làm việc ngay cả khi không có mạng, chống tình trạng không có mạng và triển khai các hoạt động tương tác phức tạp với bộ nhớ đệm như lỗi thời trong khi xác thực lại. Tuy nhiên, trước đây, trình chạy dịch vụ đã được liên kết với một nguồn gốc cụ thể. Là chủ sở hữu của ứng dụng web, bạn có trách nhiệm viết và triển khai trình chạy dịch vụ để chặn tất cả các yêu cầu mạng mà ứng dụng web của bạn đưa ra. Trong mô hình đó, mỗi worker dịch vụ đều chịu trách nhiệm xử lý ngay cả các yêu cầu trên nhiều nguồn gốc, chẳng hạn như đến một API bên thứ ba hoặc phông chữ web.

Điều gì sẽ xảy ra nếu một nhà cung cấp API, phông chữ web hoặc dịch vụ phổ biến khác của bên thứ ba có quyền triển khai worker dịch vụ của riêng họ để có cơ hội xử lý các yêu cầu do nguồn gốc khác gửi đến nguồn gốc của họ? Nhà cung cấp có thể triển khai logic kết nối mạng tuỳ chỉnh của riêng mình và tận dụng một phiên bản bộ nhớ đệm có thẩm quyền duy nhất để lưu trữ các phản hồi. Giờ đây, nhờ tìm nạp từ bên ngoài, hình thức triển khai trình chạy dịch vụ bên thứ ba đó đã trở thành hiện thực.

Việc triển khai trình chạy dịch vụ triển khai tính năng tìm nạp từ xa sẽ phù hợp với mọi nhà cung cấp dịch vụ được truy cập thông qua các yêu cầu HTTPS từ trình duyệt. Bạn chỉ cần nghĩ đến những trường hợp mà bạn có thể cung cấp phiên bản dịch vụ độc lập với mạng, trong đó trình duyệt có thể tận dụng bộ nhớ đệm tài nguyên chung. Các dịch vụ có thể hưởng lợi từ việc này bao gồm nhưng không giới hạn ở:

• Nhà cung cấp API có giao diện RESTful
• Nhà cung cấp phông chữ web
• Nhà cung cấp dịch vụ phân tích
• Nhà cung cấp dịch vụ lưu trữ hình ảnh
• Mạng phân phối nội dung chung

Ví dụ: hãy tưởng tượng bạn là một nhà cung cấp dịch vụ phân tích. Bằng cách triển khai worker dịch vụ tìm nạp từ xa, bạn có thể đảm bảo rằng tất cả yêu cầu gửi đến dịch vụ của bạn không thành công khi người dùng không có kết nối mạng đều được đưa vào hàng đợi và phát lại sau khi kết nối trở lại. Mặc dù ứng dụng của một dịch vụ có thể triển khai hành vi tương tự thông qua worker dịch vụ của bên thứ nhất, nhưng việc yêu cầu mỗi ứng dụng phải viết logic tuỳ chỉnh cho dịch vụ của bạn không có khả năng mở rộng bằng cách dựa vào worker dịch vụ tìm nạp bên ngoài dùng chung mà bạn triển khai.

Điều kiện tiên quyết

Mã thông báo Bản dùng thử theo nguyên gốc

Tính năng tìm nạp từ bên ngoài vẫn được coi là thử nghiệm. Để tránh việc quá sớm triển khai thiết kế này trước khi các nhà cung cấp trình duyệt chỉ định và đồng ý đầy đủ, thiết kế này đã được triển khai trong Chrome 54 dưới dạng Thử nghiệm gốc. Miễn là tính năng tìm nạp từ bên ngoài vẫn đang trong giai đoạn thử nghiệm, để sử dụng tính năng mới này với dịch vụ mà bạn lưu trữ, bạn cần yêu cầu mã thông báo thuộc phạm vi nguồn gốc cụ thể của dịch vụ. Mã thông báo phải được đưa vào dưới dạng tiêu đề phản hồi HTTP trong tất cả các yêu cầu nhiều nguồn gốc cho tài nguyên mà bạn muốn xử lý thông qua tính năng tìm nạp từ bên ngoài, cũng như trong phản hồi cho tài nguyên JavaScript của worker dịch vụ:

Origin-Trial: token_obtained_from_signup

Thời gian dùng thử sẽ kết thúc vào tháng 3 năm 2017. Vào thời điểm đó, chúng tôi dự kiến sẽ tìm ra mọi thay đổi cần thiết để ổn định tính năng này và (hy vọng) bật tính năng này theo mặc định. Nếu tại thời điểm đó không được bật tính năng tìm nạp bên ngoài theo mặc định, thì chức năng liên kết với mã thông báo Bản dùng thử theo nguyên gốc hiện có sẽ ngừng hoạt động.

Để tạo điều kiện thử nghiệm tính năng tìm nạp từ bên ngoài trước khi đăng ký mã thông báo chính thức cho chương trình Thử nghiệm nguồn gốc, bạn có thể bỏ qua yêu cầu trong Chrome đối với máy tính cục bộ bằng cách chuyển đến chrome://flags/#enable-experimental-web-platform-features và bật cờ "Tính năng thử nghiệm của nền tảng web". Xin lưu ý rằng cần phải thực hiện việc này trong mọi phiên bản Chrome mà bạn muốn sử dụng trong các thử nghiệm cục bộ, trong khi với mã thông báo Bản dùng thử theo nguyên gốc, tính năng này sẽ được cung cấp cho tất cả người dùng Chrome của bạn.

HTTPS

Giống như tất cả các lần triển khai trình chạy dịch vụ, bạn cần truy cập vào máy chủ web dùng để phân phát cả tài nguyên và tập lệnh trình chạy dịch vụ qua HTTPS. Ngoài ra, tính năng chặn tìm nạp từ bên ngoài chỉ áp dụng cho các yêu cầu bắt nguồn từ các trang được lưu trữ trên các nguồn gốc an toàn. Vì vậy, ứng dụng của dịch vụ cần sử dụng HTTPS để tận dụng việc triển khai tính năng tìm nạp từ bên ngoài.

Sử dụng tính năng Tìm nạp từ xa

Sau khi thiết lập xong các điều kiện tiên quyết, hãy cùng tìm hiểu chi tiết kỹ thuật cần thiết để thiết lập và chạy một trình chạy dịch vụ tìm nạp nước ngoài.

Đăng ký trình chạy dịch vụ

Thách thức đầu tiên mà bạn có thể gặp phải là cách đăng ký worker dịch vụ. Nếu đã từng làm việc với service worker trước đây, có lẽ bạn đã quen thuộc với các khái niệm sau:

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

Mã JavaScript này để đăng ký worker dịch vụ của bên thứ nhất có ý nghĩa trong bối cảnh của ứng dụng web, được kích hoạt khi người dùng chuyển đến một URL mà bạn kiểm soát. Tuy nhiên, đây không phải là phương pháp khả thi để đăng ký worker dịch vụ của bên thứ ba, khi trình duyệt chỉ có một hoạt động tương tác với máy chủ của bạn là yêu cầu một tài nguyên phụ cụ thể, chứ không phải một hoạt động điều hướng đầy đủ. Giả sử nếu trình duyệt yêu cầu một hình ảnh từ máy chủ CDN mà bạn duy trì, bạn không thể thêm đoạn mã JavaScript đó vào phản hồi của mình và kỳ vọng đoạn mã đó sẽ chạy. Bạn cần có một phương thức đăng ký worker dịch vụ khác, bên ngoài ngữ cảnh thực thi JavaScript thông thường.

Giải pháp này có dạng tiêu đề HTTP mà máy chủ của bạn có thể đưa vào bất kỳ phản hồi nào:

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

Hãy chia nhỏ tiêu đề mẫu đó thành các thành phần, mỗi thành phần được phân tách bằng một ký tự ;.

• </service-worker.js> là phần tử bắt buộc và được dùng để chỉ định đường dẫn đến tệp worker của dịch vụ (thay thế /service-worker.js bằng đường dẫn thích hợp đến tập lệnh của bạn). Điều này tương ứng trực tiếp với chuỗi scriptURL, nếu không sẽ được truyền dưới dạng tham số đầu tiên đến navigator.serviceWorker.register(). Giá trị cần được chứa trong ký tự <> (theo yêu cầu của quy cách tiêu đề Link) và nếu bạn cung cấp URL tương đối thay vì URL tuyệt đối, thì URL đó sẽ được hiểu là tương đối so với vị trí của phản hồi.
• Bạn cũng cần có rel="serviceworker" và nên đưa vào mà không cần tuỳ chỉnh.
• scope=/ là phần khai báo phạm vi không bắt buộc, tương đương với chuỗi options.scope mà bạn có thể truyền vào làm tham số thứ hai cho navigator.serviceWorker.register(). Đối với nhiều trường hợp sử dụng, bạn có thể sử dụng phạm vi mặc định, vì vậy, hãy bỏ qua phần này trừ khi bạn biết mình cần. Các quy định hạn chế tương tự về phạm vi tối đa được phép, cùng với khả năng nới lỏng các quy định hạn chế đó thông qua tiêu đề Service-Worker-Allowed, cũng áp dụng cho việc đăng ký tiêu đề Link.

Cũng giống như đăng ký trình chạy dịch vụ "truyền thống", việc sử dụng tiêu đề Link sẽ cài đặt một trình chạy dịch vụ được dùng cho yêu cầu tiếp theo được thực hiện dựa trên phạm vi đã đăng ký. Nội dung của phản hồi có tiêu đề đặc biệt sẽ được sử dụng nguyên trạng và có sẵn cho trang ngay lập tức mà không cần chờ worker dịch vụ nước ngoài hoàn tất quá trình cài đặt.

Hãy nhớ rằng tính năng tìm nạp từ bên ngoài hiện được triển khai dưới dạng Bản dùng thử theo nguyên gốc. Vì vậy, cùng với tiêu đề phản hồi Đường liên kết, bạn cũng cần thêm một tiêu đề Origin-Trial hợp lệ. Bộ tiêu đề phản hồi tối thiểu cần thêm vào để đăng ký trình chạy dịch vụ tìm nạp nước ngoài của bạn là

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

Gỡ lỗi đăng ký

Trong quá trình phát triển, bạn nên xác nhận rằng worker dịch vụ tìm nạp từ xa của mình đã được cài đặt và xử lý yêu cầu đúng cách. Bạn có thể kiểm tra một vài điểm trong Công cụ dành cho nhà phát triển của Chrome để chắc chắn rằng mọi thứ đang hoạt động như mong đợi.

Bạn có gửi các tiêu đề phản hồi thích hợp không?

Để đăng ký worker dịch vụ tìm nạp từ xa, bạn cần đặt tiêu đề Đường liên kết trên phản hồi đến một tài nguyên được lưu trữ trên miền của mình, như mô tả trước đó trong bài đăng này. Trong thời gian dùng thử theo nguyên gốc và giả sử bạn chưa đặt chrome://flags/#enable-experimental-web-platform-features, bạn cũng cần đặt tiêu đề phản hồi Origin-Trial. Bạn có thể xác nhận rằng máy chủ web của mình đang đặt các tiêu đề đó bằng cách xem mục nhập trong Bảng điều khiển mạng của DevTools:

Trình chạy dịch vụ Tìm nạp từ nước ngoài có được đăng ký đúng cách không?

Bạn cũng có thể xác nhận việc đăng ký worker dịch vụ cơ bản, bao gồm cả phạm vi của worker đó, bằng cách xem danh sách đầy đủ các worker dịch vụ trong Bảng điều khiển ứng dụng của DevTools. Hãy nhớ chọn tuỳ chọn "Hiện tất cả" vì theo mặc định, bạn sẽ chỉ thấy các worker dịch vụ cho nguồn gốc hiện tại.

Trình xử lý sự kiện cài đặt

Giờ đây, khi bạn đã đăng ký worker dịch vụ bên thứ ba, worker này sẽ có cơ hội phản hồi các sự kiện install và activate, giống như mọi worker dịch vụ khác. Ví dụ: trình quản lý bộ nhớ đệm có thể tận dụng các sự kiện đó để điền các tài nguyên cần thiết vào bộ nhớ đệm trong sự kiện install hoặc loại bỏ bộ nhớ đệm đã lỗi thời trong sự kiện activate.

Ngoài các hoạt động lưu sự kiện install vào bộ nhớ đệm thông thường, bạn còn phải thực hiện thêm một bước bắt buộc bên trong trình xử lý sự kiện install của worker dịch vụ bên thứ ba. Mã của bạn cần gọi registerForeignFetch(), như trong ví dụ sau:

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

Có hai chế độ cấu hình, cả hai đều bắt buộc:

• scopes nhận một mảng gồm một hoặc nhiều chuỗi, mỗi chuỗi đại diện cho một phạm vi cho các yêu cầu sẽ kích hoạt sự kiện foreignfetch. Nhưng chờ đã, bạn có thể đang nghĩ rằng Tôi đã xác định phạm vi trong quá trình đăng ký trình chạy dịch vụ! Điều đó đúng và phạm vi tổng thể vẫn có liên quan – mỗi phạm vi mà bạn chỉ định ở đây phải bằng hoặc một phạm vi phụ của phạm vi tổng thể của trình chạy dịch vụ. Các quy tắc hạn chế về phạm vi bổ sung tại đây cho phép bạn triển khai một worker dịch vụ đa năng có thể xử lý cả sự kiện fetch của bên thứ nhất (đối với các yêu cầu được thực hiện từ trang web của riêng bạn) và sự kiện foreignfetch của bên thứ ba (đối với các yêu cầu được thực hiện từ các miền khác), đồng thời làm rõ rằng chỉ một tập hợp con trong phạm vi lớn hơn của bạn mới kích hoạt foreignfetch. Trên thực tế, nếu đang triển khai một trình chạy dịch vụ chỉ chuyên xử lý các sự kiện foreignfetch của bên thứ ba, bạn chỉ nên sử dụng một phạm vi rõ ràng, bằng với phạm vi tổng thể của trình chạy dịch vụ. Đó là những gì ví dụ ở trên sẽ thực hiện, sử dụng giá trị self.registration.scope.
• origins cũng lấy một mảng gồm một hoặc nhiều chuỗi và cho phép bạn hạn chế trình xử lý foreignfetch chỉ phản hồi các yêu cầu từ các miền cụ thể. Ví dụ: nếu bạn cho phép rõ ràng "https://example.com", thì yêu cầu được thực hiện từ một trang được lưu trữ tại https://example.com/path/to/page.html cho một tài nguyên được phân phát từ phạm vi tìm nạp nước ngoài sẽ kích hoạt trình xử lý tìm nạp nước ngoài, nhưng các yêu cầu được thực hiện từ https://random-domain.com/path/to/page.html sẽ không kích hoạt trình xử lý. Trừ phi bạn có lý do cụ thể để chỉ kích hoạt logic tìm nạp từ xa cho một tập hợp con các nguồn gốc từ xa, bạn chỉ cần chỉ định '*' làm giá trị duy nhất trong mảng và tất cả các nguồn gốc sẽ được cho phép.

Trình xử lý sự kiện foreignfetch

Giờ đây, khi bạn đã cài đặt trình chạy dịch vụ của bên thứ ba và đã định cấu hình trình chạy dịch vụ đó thông qua registerForeignFetch(), trình chạy dịch vụ đó sẽ có cơ hội chặn yêu cầu tài nguyên phụ trên nhiều nguồn gốc đến máy chủ của bạn nằm trong phạm vi tìm nạp từ bên ngoài.

Trong worker dịch vụ truyền thống của bên thứ nhất, mỗi yêu cầu sẽ kích hoạt một sự kiện fetch mà worker dịch vụ của bạn có cơ hội phản hồi. Worker dịch vụ bên thứ ba của chúng tôi có cơ hội xử lý một sự kiện hơi khác, có tên là foreignfetch. Về mặt khái niệm, hai sự kiện này khá giống nhau và cho phép bạn kiểm tra yêu cầu sắp tới và tuỳ ý cung cấp phản hồi cho yêu cầu đó thông qua 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']
        };
    })
    );
});

Mặc dù có những điểm tương đồng về mặt khái niệm, nhưng có một số điểm khác biệt trong thực tế khi gọi respondWith() trên ForeignFetchEvent. Thay vì chỉ cung cấp Response (hoặc Promise phân giải bằng Response) cho respondWith(), như bạn làm với FetchEvent, bạn cần truyền Promise phân giải bằng một Đối tượng có các thuộc tính cụ thể đến respondWith() của ForeignFetchEvent:

• response là bắt buộc và phải được đặt thành đối tượng Response sẽ được trả về cho ứng dụng khách đã đưa ra yêu cầu. Nếu bạn cung cấp bất kỳ giá trị nào khác ngoài Response hợp lệ, yêu cầu của ứng dụng sẽ bị chấm dứt kèm theo lỗi mạng. Không giống như khi gọi respondWith() bên trong trình xử lý sự kiện fetch, bạn phải cung cấp Response tại đây, chứ không phải Promise phân giải bằng Response! Bạn có thể tạo phản hồi thông qua một chuỗi hứa hẹn và truyền chuỗi đó làm tham số đến respondWith() của foreignfetch, nhưng chuỗi phải phân giải bằng một Đối tượng chứa thuộc tính response được đặt thành đối tượng Response. Bạn có thể xem phần minh hoạ về điều này trong mã mẫu ở trên.
• origin là không bắt buộc và dùng để xác định xem phản hồi được trả về có không rõ ràng hay không. Nếu bạn bỏ qua thuộc tính này, phản hồi sẽ không rõ ràng và ứng dụng sẽ có quyền truy cập hạn chế vào phần nội dung và tiêu đề của phản hồi. Nếu yêu cầu được thực hiện bằng mode: 'cors', thì việc trả về một phản hồi mờ sẽ được coi là lỗi. Tuy nhiên, nếu chỉ định một giá trị chuỗi bằng với nguồn gốc của ứng dụng từ xa (có thể lấy qua event.origin), thì bạn đang chọn sử dụng một phản hồi hỗ trợ CORS cho ứng dụng.
• headers cũng không bắt buộc và chỉ hữu ích nếu bạn cũng đang chỉ định origin và trả về phản hồi CORS. Theo mặc định, chỉ những tiêu đề trong danh sách tiêu đề phản hồi được liệt kê trong danh sách an toàn CORS mới được đưa vào phản hồi của bạn. Nếu bạn cần lọc thêm nội dung trả về, các tiêu đề sẽ lấy danh sách một hoặc nhiều tên tiêu đề. Đồng thời, tiêu đề này sẽ sử dụng danh sách đó làm danh sách cho phép cho những tiêu đề nào sẽ hiển thị trong phản hồi. Điều này cho phép bạn chọn sử dụng CORS trong khi vẫn ngăn các tiêu đề phản hồi có thể nhạy cảm được hiển thị trực tiếp cho ứng dụng khách từ xa.

Điều quan trọng bạn cần lưu ý là khi chạy trình xử lý foreignfetch, trình xử lý này sẽ có quyền truy cập vào tất cả thông tin xác thực và quyền truy cập xung quanh của nguồn gốc lưu trữ trình chạy dịch vụ. Là nhà phát triển triển khai worker dịch vụ hỗ trợ tính năng tìm nạp từ xa, bạn có trách nhiệm đảm bảo không rò rỉ bất kỳ dữ liệu phản hồi đặc quyền nào mà bạn không thể truy cập được bằng các thông tin xác thực đó. Việc yêu cầu người dùng chọn sử dụng các phản hồi CORS là một bước để hạn chế việc vô tình tiết lộ thông tin xác thực. Tuy nhiên, với tư cách là nhà phát triển, bạn có thể tạo các yêu cầu fetch() rõ ràng bên trong trình xử lý foreignfetch không sử dụng thông tin xác thực ngầm ẩn thông qua:

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}))
    );
});

Những điều cần cân nhắc đối với ứng dụng

Có một số điểm cần cân nhắc khác ảnh hưởng đến cách worker dịch vụ tìm nạp ở nước ngoài xử lý các yêu cầu được thực hiện từ ứng dụng của dịch vụ.

Ứng dụng có worker dịch vụ của bên thứ nhất

Một số khách hàng sử dụng dịch vụ của bạn có thể đã có trình chạy dịch vụ bên thứ nhất của riêng họ, xử lý các yêu cầu bắt nguồn từ ứng dụng web của họ. Điều này ảnh hưởng gì đến trình chạy dịch vụ tìm nạp bên thứ ba của bạn?

(Các) trình xử lý fetch trong worker dịch vụ của bên thứ nhất có cơ hội đầu tiên để phản hồi tất cả các yêu cầu do ứng dụng web đưa ra, ngay cả khi có worker dịch vụ của bên thứ ba đã bật foreignfetch với phạm vi bao gồm yêu cầu đó. Tuy nhiên, các ứng dụng có worker dịch vụ của bên thứ nhất vẫn có thể tận dụng worker dịch vụ tìm nạp từ bên ngoài!

Bên trong trình chạy dịch vụ của bên thứ nhất, việc sử dụng fetch() để truy xuất tài nguyên trên nhiều nguồn gốc sẽ kích hoạt trình chạy dịch vụ tìm nạp từ bên ngoài thích hợp. Điều đó có nghĩa là mã như sau có thể tận dụng trình xử lý 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));
});

Tương tự, nếu có trình xử lý tìm nạp của bên thứ nhất nhưng các trình xử lý này không gọi event.respondWith() khi xử lý các yêu cầu đối với tài nguyên trên nhiều nguồn gốc, thì yêu cầu sẽ tự động "chuyển sang" trình xử lý 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.
});

Nếu trình xử lý fetch của bên thứ nhất gọi event.respondWith() nhưng không sử dụng fetch() để yêu cầu tài nguyên trong phạm vi tìm nạp từ bên ngoài, thì trình chạy dịch vụ tìm nạp từ bên ngoài sẽ không có cơ hội xử lý yêu cầu đó.

Những khách hàng không có nhân viên dịch vụ riêng

Tất cả ứng dụng gửi yêu cầu đến dịch vụ của bên thứ ba đều có thể hưởng lợi khi dịch vụ triển khai một worker dịch vụ tìm nạp từ bên ngoài, ngay cả khi các ứng dụng đó chưa sử dụng worker dịch vụ của riêng mình. Khách hàng không cần phải làm gì để chọn sử dụng trình chạy dịch vụ tìm nạp nước ngoài, miễn là họ đang sử dụng trình duyệt có hỗ trợ trình chạy đó. Điều này có nghĩa là bằng cách triển khai một trình chạy dịch vụ tìm nạp nước ngoài, logic yêu cầu tuỳ chỉnh và bộ nhớ đệm dùng chung của bạn sẽ mang lại lợi ích ngay lập tức cho nhiều khách hàng của dịch vụ mà không cần họ phải thực hiện thêm bước nào.

Kết hợp kiến thức đã học: nơi khách hàng tìm kiếm câu trả lời

Xem xét thông tin ở trên, chúng ta có thể tập hợp một hệ phân cấp các nguồn mà ứng dụng sẽ sử dụng để tìm phản hồi cho một yêu cầu trên nhiều nguồn gốc.

1. Trình xử lý fetch của trình chạy dịch vụ bên thứ nhất (nếu có)
2. Trình xử lý foreignfetch của trình chạy dịch vụ bên thứ ba (nếu có và chỉ dành cho các yêu cầu trên nhiều nguồn gốc)
3. Bộ nhớ đệm HTTP của trình duyệt (nếu có phản hồi mới)
4. Mạng

Trình duyệt sẽ bắt đầu từ trên cùng và tuỳ thuộc vào cách triển khai trình chạy dịch vụ, sẽ tiếp tục xuống dưới danh sách cho đến khi tìm thấy nguồn cho phản hồi.

Tìm hiểu thêm

• Nội dung giải thích về tính năng tìm nạp từ bên ngoài
• Mã mẫu và bản minh hoạ trực tiếp
• Công cụ theo dõi lỗi của trình chạy dịch vụ

Cập nhật thông tin mới nhất

Việc triển khai tính năng Thử nghiệm theo nguyên gốc của Chrome về tính năng tìm nạp từ nguồn nước ngoài có thể thay đổi khi chúng tôi giải quyết ý kiến phản hồi của nhà phát triển. Chúng tôi sẽ cập nhật bài đăng này thông qua các thay đổi cùng dòng và sẽ ghi chú những thay đổi cụ thể ở bên dưới khi chúng xảy ra. Chúng tôi cũng sẽ chia sẻ thông tin về những thay đổi lớn thông qua tài khoản Twitter @chromiumdev.