7. Operational Considerations
7. Operational Considerations
7.1. Load Management
Un push service può dover mantenere moltissime connessioni TCP aperte. Spostare le connessioni tra istanze può essere necessario.
L'user agent MUST supportare 307 (Temporary Redirect) [RFC7231] per ridistribuire il carico alla richiesta di nuovo abbonamento.
HTTP Alternative Services [RFC7838] consentono ridistribuzione mantenendo gli stessi URI; GOAWAY dopo una connessione sostitutiva permette transizione graduale.
7.2. Push Message Expiration
La memorizzazione in base a TTL può richiedere molto spazio. Il servizio non è obbligato a conservare per sempre; può indicare la durata prevista con TTL (5.2).
Un user agent che non monitora attivamente non riceve messaggi scaduti in quell'intervallo.
I messaggi memorizzati non consegnati vengono recapitati quando riprende il monitoraggio. I messaggi memorizzati SHOULD includono Last-Modified [RFC7232] (momento della richiesta di consegna).
GET su abbonamento solo con messaggi scaduti: risposta come se non fosse mai stato inviato un messaggio.
Per limitare dimensione e numero, il servizio MAY risponde 413 [RFC7231] se il corpo è troppo grande; MUST NOT 413 per corpi fino a 4096 byte.
Per limitare il numero, MAY rispondere con TTL più breve della richiesta. Dopo accettazione, MAY far scadere prima del TTL annunciato; se era richiesta ricevuta, MUST risposta di errore (6.2).
7.3. Subscription Expiration
Può essere necessario terminare gli abbonamenti per rinnovarli (messaggi e ricevute).
Il servizio MAY far scadere un abbonamento in qualsiasi momento. Richieste pendenti su risorsa scaduta (6 o 6.3) MUST essere segnalate con 404.
Invio a abbonamento messaggi scaduto: MUST 404.
L'user agent può DELETE sull'URI dell'abbonamento messaggi; il server applicativo DELETE sull'URI della receipt subscription.
7.3.1. Subscription Set Expiration
Il servizio MAY far scadere un insieme e MUST far scadere tutti gli abbonamenti nell'insieme. Richiesta pendente sull'insieme (6.1): MUST 404.
DELETE sull'URI dell'insieme MUST rimuove anche tutti gli abbonamenti nell'insieme.
Se un abbonamento membro scade o viene rimosso, MUST essere rimosso dall'insieme.
7.4. Implications for Application Reliability
Senza consegna affidabile su rete intermittente o applicazioni difettose, il dispositivo deve confermare direttamente ai server applicativi, con maggior consumo energetico.
L'affidabilità conta se i messaggi portano stato critico; altrimenti ritrasmissioni, polling e risincronizzazione costano.
Le ricevute di consegna evitano canali alternativi che annullano i vantaggi del push.
Per messaggi transitori o rapidamente superati, l'affidabilità può essere meno necessaria.
7.5. Subscription Sets and Concurrent HTTP/2 Streams
Se il servizio richiede gli insiemi, MAY limitare i flussi concorrenti con SETTINGS_MAX_CONCURRENT_STREAMS [RFC7540]. L'user agent MAY avere un flusso per gestire abbonamenti e uno per ogni insieme restituito, forzando serializzazione delle sottoscrizioni.