Utilizzo dell'intestazione dell'intervallo HTTP con un identificatore di intervallo diverso dai byte?

Question

La questione centrale è di circa l'uso delle intestazioni HTTP, tra Range, If-Range, Accept-Ranges e un intervallo definito dall'utente specificatore.

Ecco un esempio fabbricato per illustrare la mia domanda. Supponiamo che io abbia un'applicazione in stile Web 2.0 che visualizza una sorta di documenti leggibili dall'uomo. Questi documenti sono suddivisi in modo editoriale in pagine (simili agli articoli che vedi nei siti Web delle notizie). Per questo esempio, si supponga:

• C'è un documento intitolato "HTTP Gamma Question" è suddiviso in tre pagine.
• La pagina di shell (/document/shell/http-range-question) conosce le meta informazioni sul documento, incluso il numero di pagine.
• La prima pagina leggibile del documento viene caricata durante l'evento onload della pagina tramite un GET ajax e inserita nella pagina.
• Un controllo dell'interfaccia utente che assomiglia a [1 2 3 Tutti] si trova nella parte inferiore della pagina e facendo clic su un numero verrà visualizzata la pagina leggibile (caricata anche tramite ajax) e facendo clic su "Tutto" verrà visualizzato il intero documento. Assumere questi URL per il 1, 2, 3 e Tutti i casi di utilizzo:
  • /document/content/http-range-question?page=1
  • /document/content/http-range-question?page=2
  • /document/content/http-range-question?page=3
  • /document/content/http-range-question

ora alla questione. Posso usare le intestazioni del range HTTP invece che parte dell'URL (ad esempio un parametro querystring)? Forse qualcosa di simile su richiesta GET /document/content/http-range-question:

Range: page=1 

Sembra che la specifica definisce solo byte varia come consentito, quindi, anche se ho fatto le mie chiamate ajax lavorare con il mio browser e il codice del server, qualsiasi cosa in mezzo potrebbe rompersi il contratto (es. un server proxy di caching).

Range: bytes=0-499 

Tutte le opinioni o esempi reali di identificatori di gamma personalizzato?

Aggiornamento: Ho trovato una domanda simile circa l'intestazione Range (Paging in a Rest Collection) dove si menzionano che Dojo di JsonRestStore utilizza un valore di intestazione intervallo personalizzato.

Range: items=0-24 

Answer 1

Assolutamente, sei libero di specificare qualsiasi unità di intervallo che ti piace.

Da RFC 2616:

3.12 Unità di gamma

HTTP/1.1 consente a un client di richiedere che solo una parte (una serie di) l'entità
risposta da inserire all'interno della risposta . HTTP/1.1 utilizza le unità di intervallo nell'intervallo (sezione 14.35) e Intervallo di contenuto (sezione 14.16)
campi di intestazione. Un'entità può essere suddivisa in subranges secondo varie unità strutturali.

range-unit  = bytes-unit | other-range-unit 
    bytes-unit  = "bytes" 
    other-range-unit = token 

L'unica unità intervallo definito da HTTP/1.1 è "byte". Le implementazioni HTTP/1.1
POSSONO ignorare gli intervalli specificati utilizzando altre unità.

Il pezzo chiave è l'ultimo paragrafo. In realtà quello che sta dicendo è che quando hanno scritto le specifiche per HTTP/1.1, hanno solo delineato il token "byte". Ma, come puoi vedere dal bit "altra gamma di unità", sei libero di trovare i tuoi specificatori di token.

Fornire i propri specificatori di intervallo significa che è necessario avere il controllo sul codice client e server che utilizza tale identificatore. Quindi, se possiedi il pezzo di backend che espone l'URI "/ document/content/http-range-question", sei a posto; presumibilmente stai usando un moderno framework web che ti permette di ispezionare le intestazioni delle richieste in arrivo. Potresti quindi esaminare i valori dell'intervallo per eseguire correttamente la query di backup.

Inoltre, se controlli il codice AJAX che effettua richieste al back-end, dovresti essere in grado di impostare tu stesso l'intestazione Range.

Tuttavia, c'è un potenziale svantaggio che anticipi nella tua domanda: il potenziale per rompere il caching. Se si utilizza un'unità di intervallo personalizzata, eventuali cache tra il client e i server di origine "MAGGIO ignorare gli intervalli specificati utilizzando [unità diverse da" byte "]". Quindi, ad esempio, se hai una cache Squid/Varnish tra il fronte e il backend, non c'è alcuna garanzia che i risultati sperati verranno serviti dalla cache!

Si potrebbe anche considerare un'implementazione alternativa in cui, anziché utilizzare una stringa di query, si rende la pagina un "parametro" dell'URI; ad es .:/documento/contenuto/http-range-question/page/1. Questo probabilmente sarà un po 'più di lavoro per te lato server, ma è conforme a HTTP/1.1 e le cache dovrebbero trattarlo correttamente.

Spero che questo aiuti.

Answer 2

Sembra che si desidera modificare le specifiche HTTP solo per rimuovere un parametro querystring. Per fare ciò dovresti modificare il codice su entrambi i client per inviare l'intestazione modificata e il server a leggere dall'intestazione "Range" invece della querystring.

Il risultato finale è che questo sarà probabilmente il lavoro, ma il gioco è rompere tutti gli standard e gli strumenti esistenti per farlo.

Answer 3

L'intervallo HTTP viene in genere utilizzato per ripristinare i download interrotti senza iniziare dall'inizio.

Quello che stai cercando di fare sarebbe meglio gestito da OAI-ORE, che consente di definire le relazioni tra più documenti. (formati alternativi, componenti del tutto, ecc.)

Sfortunatamente, è un formato di metadati relativamente nuovo e non conosco alcun browser Web fornito con supporto nativo.

Answer 4

byte è l'unica unità supportata dalla specifica HTTP 1.1.