Ogni richiesta web invia i cookie del browser?

198

Non sto parlando di visualizzazioni di pagina, ma di una richiesta per un'immagine, un .jsfile, ecc.

Aggiorna Se una pagina Web ha 50 elementi, ovvero 50 richieste. Perché dovrebbe inviare i cookie SAME per ogni richiesta, non memorizza nella cache o sa di averlo già?

cookies

— mrblah
fonte

8

Non credo che la memorizzazione nella cache sia possibile in questa situazione: stiamo parlando del browser che invia i dati al server, non viceversa. Non puoi dire con certezza che il server "ce l'ha già" dopo che l'utente ha inviato una richiesta, per molte ragioni. Potrebbe esserci un gran numero di server che non parlano tra loro; il server potrebbe non voler (o avere spazio) per ricordare qualcosa sulle richieste precedenti - HTTP dovrebbe essere senza stato; ogni richiesta dovrebbe essere indipendente dal resto. Per questo motivo, i cookie, come le credenziali di autenticazione, devono essere inviati ad ogni richiesta.

— Ian Clelland,

Ho detto perché la cache non ha senso per i cookie in un aggiornamento per la mia risposta: stackoverflow.com/a/1336178/102960

— igorsantos07

198

Sì, fintanto che l'URL richiesto si trova nello stesso dominio e percorso definiti nel cookie (e tutte le altre restrizioni - sicure, httponly, non scadute, ecc.) Restano in attesa, il cookie verrà inviato per ogni richiesta.

— Ian Clelland
fonte

103

Questo, per inciso, è il motivo per cui strumenti per la velocità delle pagine come Google Page Speed o Yahoo YSlow raccomandano di pubblicare contenuti statici da un dominio separato, privo di cookie.

— Ceejayoz,

Ho detto di servire contenuto da un dominio separato nel mio aggiornamento risposta: stackoverflow.com/a/1336178/102960

— igorsantos07

È vero che il browser invia cookie Site2 quando c'è un reindirizzamento HTTP da Site1 a Site2?

— Zeigeist,

92

Come altri hanno già detto, se vengono rispettate le restrizioni relative all'host, al percorso e così via del cookie, questo verrà inviato 50 volte.

Ma hai anche chiesto perché: perché i cookie sono una funzione HTTP e HTTP è senza stato. HTTP è progettato per funzionare senza che il server memorizzi alcuno stato tra le richieste.

In effetti, il server non ha un modo solido per riconoscere quale utente sta inviando una determinata richiesta; potrebbero esserci migliaia di utenti dietro un singolo proxy web (e quindi indirizzo IP). Se i cookie non fossero inviati ad ogni richiesta, il server non avrebbe modo di sapere quale utente richiede qualsiasi risorsa.

Infine, il browser non ha idea se il server ha bisogno dei cookie o meno, sa solo che il server gli ha chiesto di inviare il cookie per qualsiasi richiesta a foo.com, quindi lo fa. A volte le immagini ne hanno bisogno (ad esempio, generate dinamicamente per utente), a volte no, ma il browser non può dirlo.

— derobert
fonte

1

È vero con HTTP 1.1, che è uno schema multiplexing? Vale a dire, le richieste sono raggruppate in una singola connessione TCP. Naturalmente ogni richiesta viene ricevuta con una copia del cookie allegato. Ma se la preoccupazione è la duplicazione della trasmissione, HTTP 1.1 è in grado di ottimizzare. Anche se non so se lo faccia davvero ...

— Chris Noe,

1

Quindi il problema diventa "a quali richieste il browser intende allegare i cookie?" Il server imposta la politica con il cookie, per decidere a quali domini e in quali percorsi URL deve essere inviato il cookie, ma poi lo dimentica. Avresti bisogno di un modo per specificare che alcune richieste nella connessione avevano il cookie e altre no. Questo sicuramente non esiste in HTTP / 1.1, tranne includendoli esplicitamente in ogni richiesta. Onestamente, una soluzione migliore (compatibile con gli standard) per ridurre la larghezza di banda sarebbe la codifica del contenuto gzip sul lato client, ma nessuno lo supporta ancora.

— Ian Clelland,

1

@Ian Clelland: il client deve inviare il primo messaggio, quindi non sa cosa invierebbe il server per Accept-Encoding (se i server inviassero quel campo, HTTP / 1.1 §14.3 dice che è un header di richiesta). E il problema è che potrebbe variare in base all'URL anche sullo stesso server e può cambiare nel tempo, quindi farlo funzionare non sarebbe banale.

— derobert,

1

@Chris: No, keepalive salva il sovraccarico di configurazione / smontaggio della connessione TCP, tutto qui. Le intestazioni complete vengono comunque inviate per ogni richiesta. Tuttavia, il pipelining (invio di più richieste senza attesa della risposta) può essere di grande aiuto. HTTP / 1.1 §8.1 fornisce dettagli.

— derobert,

21

Sì. Ogni richiesta invia i cookie che appartengono allo stesso dominio. Non sono memorizzati nella cache in quanto HTTP è senza stato, il che significa che ogni richiesta deve essere sufficiente per consentire al server di capire cosa farne. Supponiamo che tu abbia immagini accessibili solo a determinati utenti; si deve inviare il cookie di autenticazione con ognuno di quei 50 richieste, in modo che il server sa che sei tu e non qualcun altro, o un ospite, tra il pool di richieste si sta facendo.

Detto questo, i cookie potrebbero non essere inviati a causa di altre restrizioni menzionate nelle altre risposte, come l'impostazione HTTPS, il percorso o il dominio. Soprattutto lì, una cosa importante da notare: i cookie non sono condivisi tra domini. Questo aiuta a ridurre la dimensione delle chiamate HTTP per i file statici, come le immagini e gli script che hai citato.
Esempio: hai 4 cookie a www.stackoverflow.com; se fai una richiesta www.stackoverflow.com/images/logo.png, verranno inviati tutti e 4 i cookie.
Tuttavia, se richiedi stackoverflow.com/images/logo.png(nota la modifica del sottodominio) o images.stackoverflow.com/logo.png, quei 4 cookie non saranno presenti, ma forse quelli relativi a questi domini lo faranno.

Puoi leggere di più sui cookie e le immagini che richiedono, ad esempio, questo post sul blog StackOverflow .

— igorsantos07
fonte

10

No. Non tutte le richieste inviano i cookie. Dipende dalla configurazione dei cookie e dalla connessione client-server.

Ad esempio, se l' secureopzione del tuo cookie è impostata su trueallora deve essere trasmessa su una connessione HTTPS sicura. Significa che quando vedi quel sito Web con protocollo HTTP, questi cookie non verranno inviati dai browser poiché il flag sicuro è vero.

— Iman Sedighi
fonte

7

Il cookie ha una proprietà "percorso". Se "percorso = /", la risposta è Sì.

— neoedmund
fonte

Sì, potresti organizzare la struttura del tuo sito / app in modo tale che tutti gli URL che richiedono i cookie siano /app/simili o simili: manterrebbe la portabilità senza bisogno di sottodomini separati per eliminare le spese generali ridondanti. Oppure potresti abbandonare il Google Analytics ormai inutile per cominciare. Ho visto le intestazioni dei biscotti così a lungo che mi chiedo se mia nonna le stesse lavorando a maglia.

— Jake,

7

Sono passati 3 anni

C'è un altro motivo per cui un browser non invia i cookie. Puoi aggiungere un crossOriginattributo al tuo <script>tag e il valore a "anonymous". Ciò impedirà l'invio di cookie al server di destinazione. Il 99,9% delle volte, i tuoi javascript sono file statici e non generi quel codice js in base ai cookie della richiesta. Se hai 1KB di cookie e hai 200 risorse sulla tua pagina, il tuo utente sta caricando 200KB e ciò potrebbe richiedere del tempo su 3G e avere un effetto zero sulla pagina dei risultati. Visita l' attributo HTML: crossorigin per riferimento.

— Gilm
fonte

Spiega per favore.

— Jake,

4

@Jake puoi aggiungere un attributo crossOrigin al tuo tag <script> e il valore su "anonimo". Ciò impedirà l'invio di cookie al server di destinazione. Il 99,9% delle volte, i tuoi javascript sono file statici e non generi quel codice js in base ai cookie della richiesta. Se hai 1KB di cookie e hai 200 risorse sulla tua pagina, il tuo utente sta caricando 200KB e ciò potrebbe richiedere del tempo su 3G e avere un effetto zero sulla pagina dei risultati. Visita developer.mozilla.org/en-US/docs/Web/HTML/… come riferimento.

— Gil

4

So che questo è un vecchio thread. Ma ho appena notato che la maggior parte dei browser non invierà cookie per un dominio se aggiungi un punto finale. Ad esempio http://example.com., non riceverà i cookie impostati per .example.com. Apache invece li tratta come lo stesso host. Lo trovo utile per rendere più difficile il monitoraggio interdominio per le risorse esterne che includo, ma potresti anche usarlo per motivi di prestazioni. Si noti che questa frenata convalida i httpscertificati. Ho eseguito alcuni test utilizzando i browser e i miei dispositivi. L'hacking funziona su quasi tutti i browser ad eccezione di Safari (mobile e desktop), che includerà i cookie nella richiesta.

— Gellweiler
fonte

In che modo "rende più difficile il monitoraggio interdominio per le risorse esterne che includo"? Stai parlando di Farcebook Like e di tali widget - che sappiamo tracciare la navigazione degli utenti che hanno effettuato l'accesso per errore?

— Jake,

Sì. Lo renderà più difficile, perché la maggior parte dei browser non invierà i cookie. Quindi, se stai includendo qualcosa da google.com per esempio e sei connesso a google, google non può collegare le due richieste. Ciò non è garantito difficile, alcuni browser hanno comunque inviato i cookie e ci sono metodi meno affidabili e meno utilizzati per identificare gli utenti (come gli indirizzi IP) che funzioneranno comunque. Il più grande svantaggio è che non puoi usare HTTPS, il che lo rende inutile oggi.

— Gellweiler,

0

La risposta breve è Sì. Le righe seguenti sono tratte dalla documentazione di JS

I cookie una volta venivano utilizzati per l'archiviazione lato client generale. Sebbene ciò fosse legittimo quando rappresentavano l'unico modo per archiviare i dati sul client, si consiglia ora di utilizzare le moderne API di archiviazione. I cookie vengono inviati con ogni richiesta, quindi possono peggiorare le prestazioni (soprattutto per le connessioni dati mobili).

— Yashwin Munsadwala
fonte