Ogni richiesta web ha inviato il cookie del browser?Ogni richiesta web invia i cookie del browser?
Non sto parlando visualizzazione della pagina, ma la richiesta di un'immagine, un file .js, ecc
Aggiornamento Se una pagina web ha 50 elementi, vale a dire 50 richieste. Perché dovrebbe inviare i cookie SAME per ogni richiesta, non memorizza nella cache o sa di averla già?
Sì, finché l'URL richiesto è all'interno dello stesso dominio e percorso definito nel cookie (e tutte le altre restrizioni - sicuro, httponly, non scaduto, ecc.), Il cookie verrà inviato per ogni richiesta
Questo, per inciso, è il motivo per cui gli strumenti per la velocità della pagina come Google Page Speed o Yahoo YSlow consigliano di pubblicare contenuti statici da un dominio separato e privo di cookie. – ceejayoz
come viene inviato il cookie posso controllare md5sum del file cookie che viene inviato sul mio server ?? per favore, rispondo che ho un grosso dubbio in questo? –
Sì. Ogni richiesta invia i cookie che appartengono allo stesso dominio.
Come: si hanno 4 cookie sul sito www.stackoverflow.com. Se si effettua una richiesta a www.stackoverflow.com/images/logo.png, invierà anche i cookie.
Ma se si richiede stackoverflow.com/images/logo.png o images.stackoverflow.com/logo.png, se non ci sono cookie lì, quindi non verrà inviato alcun cookie.
È possibile leggere ulteriori informazioni su cookie e immagini richiedendo, ad esempio, a questo StackOverflow Blog Post.
Come altri hanno detto, se l'host del cookie, percorso, ecc restrizioni sono soddisfatte, sarà inviato, 50 volte.
Ma hai anche chiesto il motivo: perché i cookie sono una funzionalità HTTP e HTTP è senza stato. HTTP è progettato per funzionare senza che il server memorizzi uno stato tra le richieste.
Infatti, il server non ha un solido modo di riconoscere quale utente sta inviando una determinata richiesta; ci potrebbe essere un migliaio di utenti dietro un singolo proxy web (e quindi un indirizzo IP). Se i cookie non sono stati inviati ogni richiesta, il server non avrebbe modo di sapere quale utente sta richiedendo qualsiasi risorsa.
Infine, il browser non ha idea se il server ha bisogno o meno dei cookie, solo sa che il server ha richiesto di inviare il cookie per qualsiasi richiesta a foo.com, quindi lo fa. A volte le immagini ne hanno bisogno (ad esempio, per utente generato dinamicamente), a volte no, ma il browser non può dirlo.
È vero con HTTP 1.1, che è uno schema multiplexing? Ad esempio, le richieste sono raggruppate in una singola connessione TCP. Naturalmente ogni richiesta viene ricevuta con una copia del cookie allegato. Ma se la preoccupazione è un sacco di duplicazione della trasmissione, HTTP 1.1 è in grado di ottimizzare. Anche se non so se effettivamente lo fa ... –
Quindi il problema diventa "a quali richieste il browser intendeva allegare i cookie?" Il server imposta la politica con il cookie, per decidere quali domini e quali percorsi di URL, il cookie deve essere rispedito, ma poi lo dimentica. Avresti bisogno di un modo per specificare che certe richieste nella connessione avevano il cookie, e altre no. Questo sicuramente non esiste in HTTP/1.1, tranne che includendoli esplicitamente in ogni richiesta. Onestamente, una soluzione migliore (compatibile con gli standard) per ridurre la larghezza di banda sarebbe codifica del contenuto gzip lato client, ma nessuno lo supporta ancora. –
@Ian Clelland: il client deve inviare il primo messaggio, quindi non sa cosa il server invierà per Accept-Encoding (erano server che inviano quel campo, HTTP/1.1 §14.3 dice che è un'intestazione di richiesta). E il problema è che potrebbe variare a seconda dell'URL anche sullo stesso server, e può cambiare nel tempo, quindi renderlo operativo non è banale. – derobert
tre anni sono passati
C'è un altro motivo per cui un navigatore web non avrebbe mandato i cookie. Alcuni codici possono utilizzare l'attributo crossOrigin dell'oggetto in anonimo per impedire l'invio di cookie.
Per favore, spiega. – Jake
@Jake è possibile aggiungere un attributo crossOrigin al tag
So che questo è un thread precedente. 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 d'altra parte li tratta come lo stesso host. Trovo che questo sia utile per rendere il monitoraggio più difficile per le risorse esterne includo dominio croce, ma si potrebbe anche usarlo per motivi di prestazioni. Notare questa convalida dei freni dei certificati https. Ho eseguito alcuni test utilizzando i browser e i miei dispositivi. L'hack funziona su quasi tutti i browser ad eccezione di Safari (mobile e desktop), che includerà i cookie nella richiesta.
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 conosciamo mentre navighiamo su utenti accidentalmente registrati? – Jake
Sì. Lo renderà più difficile, perché la maggior parte dei browser non invierà i cookie. Pertanto, se includi qualcosa da google.com ad esempio e hai effettuato l'accesso a google, Google non può collegare le due richieste. Questo non è garantito, 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 ancora. Il più grande svantaggio è che non è possibile utilizzare HTTPS, il che rende oggi inutilizzabile. – Gellweiler
No. Non ogni richiesta invia i cookie. Essa dipende dalla configurazione dei cookie e la connessione client-server.
Ad esempio, se l'opzione del tuo cookie è impostata su true, deve essere trasmessa tramite una connessione HTTPS protetta. Significa che quando vedi quel sito Web con protocollo HTTP, questi cookie non verranno inviati dai browser in quanto il flag di sicurezza è vero.
Il cookie ha una proprietà "percorso". Se "percorso = /", la risposta è Sì.
Sì, è possibile organizzare la struttura del proprio sito/app in modo tale che tutti gli URL che richiedono i cookie siano wthin/app/'o simili - conserverebbero la portabilità senza richiedere sottodomini separati per eliminare il sovraccarico ridondante. Oppure potresti abbandonare l'ormai inutile Google Analytics per cominciare.Ho visto le intestazioni dei cookie per così tanto tempo che mi chiedo se mia nonna li stesse lavorando a maglia. – Jake
Non penso che il caching sia possibile in questa situazione - stiamo parlando del browser che invia i dati al server, non viceversa. Non si può dire con certezza che il server "lo abbia già" dopo che l'utente ha inviato una richiesta, per molti motivi. Ci può essere un gran numero di server che non parlano tra loro; il server potrebbe non volere (o avere spazio) di ricordare nulla delle precedenti richieste - 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. –