matteocontrini ah, quanto sarebbe bello il mondo se tutte le implementazioni di browser e proxy seguissero pedissequamente le RFC e non ci fosse mai bisogno di direttive apparentemente insensate e in conflitto tra loro... 🙄
Secondo me qui non ha proprio senso lasciare al browser e/o al MitM la gestione della cache, in maniera totalmente aleatoria in quanto non definita esplicitamente e quindi totalmente dipendente dall'implementazione... Con risultati totalmente a caso come puoi ben vedere.
Dunque in questo caso trovo non abbia senso il nulla, ma nemmeno no-cache visto che API come questa non implementano il 304 Not Modified (ossia le coppie di If-Modified-Since + Last-Modified e/o If-None-Match + ETag), per cui in questo caso non e' possibile "evitare di trasferire inutilmente risposte identiche a quelle già presenti in locale" perche' il server non lo prevede. Per questo motivo credo che qui sarebbe invece opportuno no-store, per evitare che i client mantengano in cache inutilmente dei contenuti che poi devono comunque buttare via perche' il server non implementa il 304. Se poi un giorno venisse implementato il 304 allora avrebbe senso usare no-cache.
Tutto il resto del papiro che giustamente ti sembra ridondante (perche' lo e'), serve solo per evitare problemi con implementazioni non totalmente conformi alle RFC; non e' che mi diverto a servirlo io tanto per, un motivo ben preciso c'e' ed e' quello di assicurare retrocompatibilita' totale... Certo questo forum magari non deve supportare IE6 o chissa' quali oscuri proxy aziendali, ma perche' fare assunzioni del genere che rischiano di rompere tutto per un utente con ambiente esotico, solo per risparmiare pochi byte per risposta?
