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

J Jeff Posnick

Twitter GitHub Trang chủ

Cảnh báo: Thông tin trong bài đăng này đã lỗi thời. Tính năng tìm nạp bên ngoài không còn dùng được để kiểm thử trong Chrome và đã bị xoá khỏi thông số kỹ thuật của trình chạy dịch vụ.

Thông tin khái quát

Trình chạy dịch vụ giúp nhà phát triển web phản hồi các yêu cầu mạng do các ứ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ó kết nối mạng, chống lại lie-fi và triển khai các hoạt động tương tác phức tạp liên quan đến bộ nhớ đệm như xác thực lại đã lỗi thời. Tuy nhiên, từ trước đến nay, service worker gắn liền với một nguồn gốc cụ thể – với tư cách là chủ sở hữu ứng dụng web, bạn có trách nhiệm viết và triển khai dịch vụ để chặn tất cả yêu cầu mạng mà ứng dụng web của bạn tạo. Trong mô hình đó, mỗi trình chạy dịch vụ chịu trách nhiệm xử lý cả các yêu cầu trên nhiều nguồn gốc, ví dụ như đối với một API của bên thứ ba hoặc đối với phông chữ trên web.

Điều gì sẽ xảy ra nếu nhà cung cấp API, phông chữ trên web hoặc dịch vụ thông dụng khác của bên thứ ba có khả năng triển khai trình chạy dịch vụ của riêng họ để xử lý yêu cầu do các 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 thực thể bộ nhớ đệm duy nhất, đáng tin cậy để lưu trữ phản hồi của họ. Giờ đây, nhờ tìm nạp nước ngoài, hình thức triển khai trình chạy dịch vụ của bên thứ ba đã trở thành hiện thực.

Việc triển khai một trình chạy dịch vụ thực hiện tìm nạp bên ngoài là hợp lý đối với bất kỳ nhà cung cấp dịch vụ nào được truy cập thông qua các yêu cầu HTTPS từ các trình duyệt. Hãy nghĩ đến các tình huống trong đó bạn có thể cung cấp một phiên bản dịch vụ độc lập về mạng, trong đó các trình duyệt có thể tận dụng một 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ữ trên web
• Nhà cung cấp 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à nhà cung cấp phân tích. Bằng cách triển khai một trình chạy dịch vụ tìm nạp bên ngoài, bạn có thể đảm bảo rằng tất cả các yêu cầu đối với dịch vụ của bạn không thực hiện được khi người dùng không 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ù các ứng dụng của một dịch vụ có thể triển khai hành vi tương tự thông qua trình chạy dịch vụ bên thứ nhất, nhưng việc yêu cầu mỗi và mọi khách hàng phải viết logic riêng cho dịch vụ của bạn không thể mở rộng như việc dựa vào một trình chạy 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 dùng thử theo nguyên gốc

Hoạt động tìm nạp nước ngoài vẫn được coi là thử nghiệm. Để tránh sớm sử dụng thiết kế này trước khi các nhà cung cấp trình duyệt chỉ định đầy đủ và đồng ý, thiết kế này đã được triển khai trong Chrome 54 dưới dạng Bản dùng thử theo nguyên gốc. Miễn là tính năng tìm nạp bên ngoài vẫn còn ở 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ột mã thông báo thuộc phạm vi nguồn gốc cụ thể của dịch vụ. Bạn phải đưa mã thông báo này vào dưới dạng tiêu đề phản hồi HTTP trong tất cả các yêu cầu trên nhiều nguồn gốc đối với những tài nguyên mà bạn muốn xử lý thông qua hoạt động tìm nạp bên ngoài, cũng như trong phản hồi cho tài nguyên JavaScript của trình chạy dịch vụ:

Origin-Trial: token_obtained_from_signup

Giai đoạn dùng thử sẽ kết thúc vào tháng 3 năm 2017. Đến thời điểm đó, chúng tôi hy vọng đã xác định được 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 đó, tính năng tìm nạp ngoài chưa được bật theo mặc định, thì chức năng liên kết với các 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 phương thức tìm nạp ngoài trước khi đăng ký mã thông báo Bản dùng thử theo nguyên gốc chính thức, bạn có thể bỏ qua yêu cầu trong Chrome cho máy tính cục bộ bằng cách truy cập vào chrome://flags/#enable-experimental-web-platform-features và bật cờ "Các tính năng của Nền tảng web thử nghiệm". Xin lưu ý rằng bạn cần 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ộ, còn 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.

HTTPS

Giống như tất cả các lần triển khai trình chạy dịch vụ, máy chủ web mà bạn sử dụng để phân phối cả tài nguyên và tập lệnh trình chạy dịch vụ của bạn cần truy cập qua HTTPS. Ngoài ra, tính năng chặn tìm nạp 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 nguồn gốc bảo mật, vì vậy, các ứng dụng khách của dịch vụ cần sử dụng HTTPS để tận dụng việc triển khai tìm nạp bên ngoài của bạn.

Sử dụng Tìm nạp nước ngoài

Với các điều kiện tiên quyết, hãy đi sâu vào các 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ụ của bạn

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

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

Mã JavaScript này dùng để đăng ký trình chạy dịch vụ của bên thứ nhất có ý nghĩa trong ngữ cảnh của một ứng dụng web, được kích hoạt bởi người dùng di chuyển đến 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ý một trình chạy dịch vụ bên thứ ba, khi mà trình duyệt tương tác duy nhất với máy chủ của bạn đang yêu cầu một tài nguyên phụ cụ thể, chứ không phải một điều hướng đầy đủ. Giả sử trình duyệt yêu cầu một hình ảnh từ máy chủ CDN mà bạn duy trì, thì bạn không thể thêm đoạn mã JavaScript đó vào phản hồi của mình và mong đợi rằng đoạn mã đó sẽ chạy. Bạn phải có một phương thức đăng ký trình chạy dịch vụ khác ngoài ngữ cảnh thực thi JavaScript thông thường.

Giải pháp sẽ 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 phân tích 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à bắt buộc và được dùng để chỉ định đường dẫn đến tệp trình chạy dịch vụ của bạn (thay thế /service-worker.js bằng đường dẫn thích hợp đến tập lệnh của bạn). Chuỗi này tương ứng trực tiếp với chuỗi scriptURL sẽ được chuyển dưới dạng tham số đầu tiên vào navigator.serviceWorker.register(). Giá trị này phải được đặt 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à liên quan đến vị trí của phản hồi.
• rel="serviceworker" cũng là bắt buộc và nên được đưa vào mà không cần tuỳ chỉnh.
• scope=/ là một 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 dưới dạng tham số thứ hai cho navigator.serviceWorker.register(). Đối với nhiều trường hợp sử dụng, bạn đã chọn cách sử dụng phạm vi mặc định, vì vậy, hãy bỏ qua trường hợp này trừ phi bạn biết là mình cần đến. Các quy định hạn chế tương tự xoay quanh phạm vi tối đa được cho phép, cùng với khả năng nới lỏng những hạn chế đó thông qua tiêu đề Service-Worker-Allowed, cũng áp dụng cho gói đăng ký tiêu đề Link.

Giống như cách đă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ụ sẽ được dùng cho yêu cầu tiếp theo được thực hiện trên phạm vi đã đăng ký. Nội dung của phản hồi bao gồm 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ờ nhân viên dịch vụ nước ngoài hoàn tất cài đặt.

Hãy nhớ rằng phương thức tìm nạp 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 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 là

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

Lưu ý: Người đọc sắc nét của thông số kỹ thuật của trình chạy dịch vụ có thể đã phát hiện một phương thức khác để thực hiện đăng ký trình chạy dịch vụ qua phần tử DOM <link rel="serviceworker">. Hiện tại, tính năng hỗ trợ đăng ký dựa trên <link> trong Chrome chịu sự kiểm soát của cùng một Bản dùng thử gốc như tiêu đề Link, vì vậy tính năng này chưa được bật theo mặc định. Việc đăng ký dựa trên <link> có những hạn chế giống như đăng ký dựa trên JavaScript khi dùng để đăng ký tìm nạp nước ngoài. Vì vậy, trong bài viết này, bạn nên sử dụng tiêu đề Link.

Đăng ký gỡ lỗi

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

Các tiêu đề phản hồi có đang được gửi phù hợp không?

Để đăng ký trình chạy dịch vụ tìm nạp bên ngoài, bạn cần đặt tiêu đề Liên kết trong phản hồi cho tài nguyên được lưu trữ trên miền của bạn, như mô tả ở trên trong bài đăng này. Trong thời gian Dùng thử theo nguyên gốc và giả sử 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 Công cụ cho nhà phát triển:

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

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

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

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

Ngoài các hoạt động lưu vào bộ nhớ đệm sự kiện install thông thường, bạn bắt buộc phải thực hiện thêm một bước trong trình xử lý sự kiện install của trình chạy 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 tuỳ chọn cấu hình, cả hai đều bắt buộc:

• scopes lấy 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 các yêu cầu sẽ kích hoạt sự kiện foreignfetch. Nhưng chờ đã, bạn có thể nghĩ: Tôi đã xác định một 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 phù hợp — mỗi phạm vi bạn chỉ định ở đây phải bằng hoặc là một phạm vi phụ trong phạm vi tổng thể của trình chạy dịch vụ. Các quy định hạn chế khác về phạm vi ở đây cho phép bạn triển khai một trình chạy 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 yêu cầu được đưa ra từ trang web của bạn) và sự kiện foreignfetch của bên thứ ba (đối với những yêu cầu được đưa ra từ các miền khác), đồng thời nêu rõ rằng chỉ một phần trong phạm vi lớn hơn của bạn mới được kích hoạt foreignfetch. Trong thực tế, nếu đang triển khai một trình chạy dịch vụ chỉ dùng để xử lý các sự kiện foreignfetch của bên thứ ba, thì bạn nên sử dụng một phạm vi duy nhất, 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 bằng cách sử dụng giá trị self.registration.scope.
• origins cũng nhận 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 "https://example.com" một cách rõ ràng, thì một yêu cầu được tạo từ một trang được lưu trữ tại https://example.com/path/to/page.html cho tài nguyên được phân phát trong phạm vi tìm nạp bên ngoài sẽ kích hoạt trình xử lý tìm nạp bên ngoài, nhưng các yêu cầu được tạo từ https://random-domain.com/path/to/page.html sẽ không kích hoạt trình xử lý đó. Trừ phi có lý do cụ thể để chỉ kích hoạt logic tìm nạp bên ngoài 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à mọi nguồn gốc sẽ được cho phép.

Trình xử lý sự kiện tìm nạp nước ngoài

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

Lưu ý: Có một quy định hạn chế bổ sung trong cách triển khai hiện tại của Chrome: chỉ những yêu cầu GET, POST hoặc HEAD chỉ chứa các tiêu đề có trong danh sách an toàn của cơ chế CORS mới đủ điều kiện để tìm nạp bên ngoài. Hạn chế này không có trong quy cách tìm nạp ở nước ngoài và có thể được áp dụng trong các phiên bản Chrome trong tương lai.

Trong một trình chạy dịch vụ bên thứ nhất truyền thống, mỗi yêu cầu sẽ kích hoạt một sự kiện fetch mà trình chạy đó có cơ hội phản hồi. Trình chạy dịch vụ bên thứ ba của chúng ta có cơ hội xử lý một sự kiện hơi khác tên là foreignfetch. Về mặt lý thuyết, 2 sự kiện này khá giống nhau và chúng cung cấp cho bạn cơ hội kiểm tra yêu cầu đến, đồng thời cung cấp phản hồi cho yêu cầu đó thông qua respondWith() (không bắt buộc):

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 vẫn có một vài đ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ư thực hiện với FetchEvent, bạn cần truyền một Promise phân giải bằng một Đối tượng 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ề ứng dụng đã đưa ra yêu cầu. Nếu bạn cung cấp thông tin 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 do 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 giúp phân giải bằng Response! Bạn có thể tạo phản hồi thông qua một chuỗi lời hứa và truyền chuỗi đó dưới dạng tham số cho respondWith() của foreignfetch, nhưng chuỗi này 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ạ việc 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 bước này, phản hồi sẽ mờ 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ề phản hồi không rõ ràng 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 thể hiện rõ việc chọn cung cấp phản hồi có hỗ trợ CORS cho ứng dụng khách.
• headers cũng là không bắt buộc và chỉ hữu ích nếu bạn cũng chỉ định origin và trả về một 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 đưa vào danh sách an toàn của cơ chế phân phối VPN mới được đưa vào câu trả lời của bạn. Nếu bạn cần lọc thêm các tiêu đề được trả về, tiêu đề sẽ lấy một danh sách gồm một hoặc nhiều tên tiêu đề rồi sử dụng tên đó làm danh sách cho phép về các tiêu đề 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ó khả năng mang tính nhạy cảm hiển thị trực tiếp với ứng dụng từ xa.

Điều quan trọng bạn cần lưu ý là khi chạy, trình xử lý foreignfetch có quyền truy cập vào tất cả thông tin xác thực và quyền truy cập môi trường của nguồn gốc lưu trữ trình chạy dịch vụ. Là một nhà phát triển triển khai trình chạy dịch vụ cho phép tìm nạp bên ngoài, bạn có trách nhiệm đảm bảo rằng mình không rò rỉ bất kỳ dữ liệu phản hồi đặc quyền nào mà không có sẵn nhờ những thông tin xác thực đó. Việc yêu cầu chọn sử dụng các phản hồi CORS là một bước để hạn chế tình trạng vô tình xuất hiện, nhưng là một nhà phát triển, bạn có thể thực hiện một cách rõ ràng các yêu cầu fetch() bên trong trình xử lý foreignfetch của mình không sử dụng thông tin xác thực ngụ ý 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ểm cần cân nhắc của khách hàng

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

Những khách hàng có trình chạy dịch vụ bên thứ nhất của riêng mình

Một số ứng dụng của dịch vụ 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 như thế nào đến trình chạy dịch vụ tìm nạp nước ngoài của bên thứ ba?

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

Bên trong một trình chạy dịch vụ bên thứ nhất, việc sử dụng fetch() để truy xuất các tài nguyên nhiều nguồn gốc sẽ kích hoạt trình chạy dịch vụ tìm nạp 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 của bạn:

// 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ý yêu cầu cho tài nguyên trên nhiều nguồn gốc, thì yêu cầu đó sẽ tự động "qua" 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 bên ngoài, thì trình xử lý dịch vụ tìm nạp bên ngoài của bạn sẽ không có cơ hội xử lý yêu cầu.

Ứng dụng không có trình chạy dịch vụ riêng

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

Tập hợp tất cả lại với nhau: nơi khách hàng tìm kiếm câu trả lời

Dựa vào 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 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ụ, trình duyệt sẽ tiếp tục đi xuống trong danh sách cho đến khi tìm thấy nguồn cho phản hồi.

Tìm hiểu thêm

• Giải thích về hoạt động tìm nạp dữ liệu nước 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 Bản dùng thử theo nguyên gốc tìm nạp bên ngoài của Chrome có thể thay đổi khi chúng tôi xử lý ý kiến phản hồi của nhà phát triển. Chúng tôi sẽ luôn cập nhật bài đăng này thông qua các thay đổi nội tuyến và sẽ lưu ý các 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ề các thay đổi lớn qua tài khoản Twitter @chromiumdev.