"Code d'état: 200 OK (de ServiceWorker)" dans Chrome DevTools réseau?

Je connais les codes d'état http, mais récemment, j'ai vu une ligne étrange dans mon débogueur Chrome. Au lieu du Status Code:200 OK ordinaire Status Code:200 OK J'ai vu ce qui suit: Status Code:200 OK (from ServiceWorker) .

Entrez la description de l'image ici

Je suppose que cela me dit simplement que ServiceWorker est en quelque sorte responsable de l'accès à ce document, mais ce n'est que l'hypothèse aléatoire. Quelqu'un peut-il autoriser (sans prétexte, avec des liens vers des ressources respectées), dites-moi ce que cela signifie et quelles sont les implications?

C'est une source commune de confusion, donc j'ai voulu entrer dans un peu plus de détails.

J'ai une démonstration de travail complète dans ce Gist , et vous pouvez voir une version en direct grâce à RawGit.

Voici la partie pertinente du code du travailleur en ligne, à titre illustratif:

 self.addEventListener('fetch', event => { if (event.request.url.endsWith('one.js')) { // Requests for one.js will result in the SW firing off a fetch() request, // which will be reflected in the DevTools Network panel. event.respondWith(fetch(event.request)); } else if (event.request.url.endsWith('two.js')) { // Requests for two.js will result in the SW constructing a new Response object, // so there won't be an additional network request in the DevTools Network panel. event.respondWith(new Response('// no-op')); } // Requests for anything else won't trigger event.respondWith(), so there won't be // any SW interaction reflected in the DevTools Network panel. }); 

Et voici comment apparait une version filtrée du panneau réseau dans Chrome 48 lorsque ce travailleur du service contrôle le one.js d'une page, et les demandes sont faites pour one.js , two.js et three.js :

Panneau réseau Chrome DevTools

Le gestionnaire de fetch de notre travailleur de service fera l'une des trois choses suivantes:

  • S'il s'agit d'une demande pour one.js , il déclenchera une requête fetch() pour la même URL, puis appeler event.respondWith() utilisant cette réponse. La première one.js dans la capture d'écran, celle avec "(de ServiceWorker)" dans la colonne "Taille", est en vertu du fait que nous avons appelé event.respondWith() dans le gestionnaire d' fetch . La deuxième one.js dans la capture d'écran, celle avec l'icône petit engin à côté de celle-ci et "(à partir du cache)" dans la colonne "Taille", représente cette requête fetch() qui a été faite dans le service après-vente en réponse à l'événement. Étant donné que le fichier one.js actuel était déjà dans le cache HTTP au point où j'ai pris cette capture d'écran, vous voyez "(à partir du cache)", mais si le cache HTTP n'avait déjà pas cette réponse, vous verriez une requête réseau réelle Ainsi que la taille de la réponse.
  • S'il s'agit d'une requête pour two.js , il traitera la demande en construisant un nouvel objet de Response "à partir de l'air". (Oui, vous pouvez le faire!) Dans ce cas, nous appelons event.respondWith() , il y a donc une entrée pour two.js avec "(de ServiceWorker)" dans la colonne "Taille". Mais contrairement à one.js , nous n'utilisons pas fetch() pour remplir la réponse, donc il n'y a pas d'entrée supplémentaire dans le panneau Network pour two.js
  • Enfin, s'il s'agit d'une requête pour three.js , le gestionnaire d'événements de fetch de notre travailleur de service n'appellera pas event.respondWith() . Du point de vue de la page, et aussi du point de vue du panneau du réseau, il n'y a pas d'implication des travailleurs du service avec cette demande, c'est pourquoi il n'y a qu'un "(du cache)" plutôt que "(de ServiceWorker)" dans la "Taille "Colonne.

Un travailleur de service est un script qui est géré par votre navigateur en arrière-plan. Ainsi, le code de statut: 200 OK (de ServiceWorker) signifie que le code de réussite "OK", pour la requête GET ou HEAD et ce statut proviennent de ServiceWorker.

Vous pouvez lire ce lien pour en savoir plus à ce sujet. http://www.html5rocks.com/fr/tutorials/service-worker/introduction/

C'est normal . Pour éviter toute confusion découlant de 200 pour chaque demande. Il montre que la demande est un SUCCESS mais le service-worker a répondu pour la ressource / demande au lieu du network/server