“Codice di stato: 200 OK (da ServiceWorker)” in Chrome Network DevTools?

Ho familiarità con i codici di stato http, ma recentemente ho visto una strana riga nel mio debugger di Chrome. Invece del normale Status Code:200 OK ho visto quanto segue: Status Code:200 OK (from ServiceWorker) .

inserisci la descrizione dell'immagine qui

La mia ipotesi è che questo mi dica solo che ServiceWorker è in qualche modo responsabile dell’accesso a questo documento, ma questa è solo un’ipotesi casuale. Qualcuno può autorevolmente (senza supposizioni, con collegamenti a risorse rispettate) dirmi cosa significa e quali sono le implicazioni?

Questa è una fonte comune di confusione, quindi ho voluto entrare un po ‘più in dettaglio.

Ho una demo completamente funzionante in questo Gist , e puoi vederne una versione live grazie a RawGit.

Ecco la parte rilevante del codice del lavoratore di servizio in linea, a scopo illustrativo:

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

Ecco come appare una versione filtrata del pannello Rete in Chrome 48 quando l’ one.js two.js controllo di una pagina e vengono fatte richieste per one.js , two.js e three.js :

Pannello di rete di Chrome DevTools

Il gestore di fetch addetto ai servizi farà una delle tre cose:

  • Se si tratta di una richiesta per one.js , verrà one.js una richiesta fetch() per lo stesso URL e quindi richiamerà event.respondWith() utilizzando tale risposta. La prima entry one.js nello screenshot, quella con “(da ServiceWorker)” nella colonna “Size”, è presente in virtù del fatto che abbiamo chiamato event.respondWith() all’interno del gestore di fetch . La seconda voce one.js nello screenshot, quella con la piccola icona dell’ingranaggio accanto ad essa e “(dalla cache)” nella colonna “Dimensione”, rappresenta quella richiesta fetch() che è stata creata all’interno dell’operatore del servizio durante la risposta a l’evento. Poiché il file one.js effettivo era già nella cache HTTP nel punto in cui ho scattato questa schermata, viene visualizzato “(dalla cache)”, ma se la cache HTTP non aveva già quella risposta, si vedrebbe una richiesta di rete effettiva insieme alle dimensioni della risposta.
  • Se è una richiesta per two.js , gestirà la richiesta costruendo un nuovo object Response “dal two.js “. (Sì, puoi farlo!) In questo caso, stiamo chiamando event.respondWith() , quindi c’è una voce per two.js con “(da ServiceWorker)” nella colonna “Dimensione”. Ma diversamente da one.js , non usiamo fetch() per popolare la risposta, quindi non ci sono voci aggiuntive nel pannello Network per two.js
  • Infine, se si tratta di una richiesta per three.js , il gestore dell’evento di fetch del nostro operatore di servizio non chiamerà in realtà event.respondWith() . Dal punto di vista della pagina, e anche dal punto di vista del pannello Network, non vi è alcun coinvolgimento del service worker con quella richiesta, motivo per cui c’è solo un “(dalla cache)” piuttosto che “(da ServiceWorker)” nella “Dimensione” “colonna.

Un lavoratore di servizio è uno script che viene eseguito dal browser in background. Quindi Codice di stato: 200 OK (da ServiceWorker) significa che il codice di successo “OK”, per la richiesta GET o HEAD e questo stato proviene da ServiceWorker.

Puoi leggere questo link per capire di più su questo. http://www.html5rocks.com/en/tutorials/service-worker/introduction/

E ‘normale . Per evitare confusione derivante da 200 per ogni richiesta. La sua dimostrazione che la richiesta è un SUCCESS ma l’ service-worker ha risposto per la risorsa / richiesta invece di network/server