come può un server Web conoscere tutte le schede da esso fornite (per la stessa sessione) nello stesso browser?

Poiché i cookie o i dati di sessione sono condivisi tra tutte le schede dello stesso sito, non possono essere utilizzati per identificare le schede.

Il modo più semplice per distinguere le "sessioni" separate con gli stessi cookie è codificare lo stato della sessione negli URL. Per ogni risposta inviata dal server, qualsiasi collegamento in quella risposta contiene un token che consente di correlare la richiesta risultante con quella risposta precedente. Invece di token astratti, l'URL potrebbe anche codificare lo stato dell'interfaccia utente completo.

Questo approccio è stato utilizzato in alcune vecchie applicazioni Web Java prima che l'interfaccia utente lato client con JavaScript diventasse valida. Poiché l'intero codice HTML è stato reso lato server, il server doveva conoscere lo stato esatto dell'interfaccia utente, ad es. quali schede sono attualmente selezionate o quali nodi sono espansi in una vista ad albero.

Un esempio di token astratti:

• Scheda client 1: GET /foo HTTP/1.1

• Il server risponde con un documento in cui tutti i collegamenti contengono un token:

  HTTP/1.1 200 OK
  Content-Type: text/html
  
  <a href="/foo?token=123abc"> reload </a>
  <a href="/bar?token=123abc"> different page </a>
  

• Il client apre il link di ricarica in una nuova scheda: GET /foo?token=123abc HTTP/1.1

• Il server risponde con un nuovo token:

  HTTP/1.1 200 OK
  Content-Type: text/html
  
  <a href="/foo?token=234bcd"> reload </a>
  <a href="/bar?token=234bcd"> different page </a>
  

Il browser ora ha due set di token e il server sarà in grado di dire da quale pagina è stata fatta una richiesta. Questo potrebbe essere visualizzato come un albero di storie:

              /foo
                |
        /foo?token=123abc
          /            \
/foo?token=23bcd    /foo?token=345cde
          |
/bar?token=456def

(Tecniche simili sono utilizzate per far rispettare una richiesta da una determinata pagina, ad es. per difendersi da CSRF. I token anti-CSRF sono nonces, quindi qualsiasi cronologia di branching sarebbe un errore.)

Questo approccio ha ancora un paio di restrizioni. Ad esempio, rende impossibile il caching. In particolare, non è possibile per il server vedere una differenza tra fare due richieste dalla stessa scheda che apre un'altra scheda, rispetto a fare una richiesta, quindi tornare nella cronologia del browser alla pagina precedente e fare un'altra richiesta.

Il problema concettuale è che un sistema distribuito come Internet è poco adatto per mantenere lo stato condiviso tra i nodi. HTTP in particolare è un protocollo completamente stateless che non ha alcun concetto di connessione attiva. (Il protocollo HTTP moderno presenta in realtà protocolli di trasporto con stato, ma ogni coppia richiesta-risposta a livello di applicazione è ancora molto stateless.)

Ciò che HTTP è in grado di fare è lo stato trasferimento tra il server e il client, che è l'intuizione che è stata successivamente formalizzata come stile RESTful. Cioè lo stato completo pertinente del client deve essere codificato nell'URL della richiesta, nelle intestazioni (inclusi i cookie) o nel payload della richiesta.

Il server deve mantenere lo stato zero per connessione perché non ci sono connessioni e perché dovrebbe ricevere lo stato pertinente dal client. Pertanto, l'argomento della garbage collection viene anche eluso. In un progetto RESTful il client può far sì che il server memorizzi o modifichi risorse a cui è possibile accedere in seguito, ma non è possibile per il server stabilire se tali risorse vengano referenziate esternamente. Invece, dovresti eliminare le risorse transitorie solo dopo che è trascorso un certo periodo di tempo senza accesso.

Il risultato insoddisfacente è che è davvero difficile creare applicazioni web multi-tab che funzionino come previsto. La maggior parte delle app web non prenderà in considerazione questo caso e si interromperà semplicemente quando lo stato della sessione viene modificato da più schede, o sono così completamente client che non ci sono stati / cookie di sessione oltre a un cookie che indica se l'utente ha effettuato l'accesso. caso, il client stesso può essere stato e qualsiasi comunicazione con il server avverrebbe tramite richieste Ajax che ora non devono codificare lo stato completo del client. Cioè non ci sarebbero collegamenti ipertestuali ordinari per l'utente a seguire se stessi.