Push API, vantaggi e possibili rischi

La bozza di lavoro per le Push API presentata recentemente dal World Wide Web Consortium, potrebbe rappresentare un primo passo verso la creazione di un standard concepito per superare alcuni limiti imposti dall'utilizzo di HTTP; una delle caratteristche di questo protocollo è infatti quella di essere stateless, cià significa che esso non archivia le connessioni client/server.

In parole semplici, tramite HTTP un server non può effettuare l'invio di dati (Push mode) verso un client con il quale sia stata stabilita precedentemente una connessione, tale fenomeno è dovuto all'assenza di stato del protocollo; data una limitazione del genere, il compito di richiedere notifiche al server spetterà  obbligatoriamente al client (Pull mode).

Quello che ora può sembrare unicamente uno svantaggio, ha permesso fino ad ora di semplificare il lavoro di progettazione dei Web server liberandoli dall'onere di memorizzare le informazioni relative alle connessioni attivate; i protocolli stateless, a differenza di quelli stateful, manipolano infatti ogni richiesta come se si trattasse di un'entità  indipendente rispetto a qualsiasi altra transazione formulata in precedenza.

Come risolvere quindi il problema dovuto alla necessità  di inviare continuamente nuove informazioni da far interpretare al server pur rimanendo in un contesto "di Rete"? La proposta del W3C potrebbe essere quella di valutare l'impiego di soluzioni già  in implementazione, come per esempio quelle dedicate al real-time messaging cloud-hosted o pensate per dotare le Web applications di funzionalità  real-time tramite WebSockets HTML5. Il tutto nell'ottica di identificare uno standard.

L'introduzione di specifiche sulle interfacce di programmazione per le notifiche Push, non rappresenterebbe però un percorso esente da rischi; innanzitutto andrebbero risolte tutte le problematiche relative all'autenticazione e all'autorizzazione, in secondo luogo, se Push mode deve essere, questo dovrebbe consentire di inviare richieste anche a Web applications inattive, il che potrebbe spianare la strada a nuove occasioni di attacchi basati sul Denial of Service da parte di utenti malintenzionati.