2014-11-22 11 views
6

Prima di iniziare una richiesta di intervallo, per prima cosa controlla se è supportato utilizzando una richiesta HEAD. Normalmente torno qualcosa del genere:Una risorsa HTTP che accetta richieste di intervallo specifica sempre la lunghezza del contenuto?

curl -X HEAD -i http://bits.wikimedia.org/images/wikimedia-button.png 

HTTP/1.1 200 OK 
... 
Content-Length: 2426 
Accept-Ranges: bytes 
... 

La lunghezza del contenuto è garantita in base alle specifiche HTTP/1.1 in questo caso? Non riesco a trovare una risposta definitiva ma sembra che avrei bisogno di conoscere la lunghezza del contenuto prima di fare una richiesta di intervallo.

risposta

5

No.

Come per qualsiasi altra risposta con codice di stato 200, una tale risposta DEVONO (nel RFC 2119 senso di "DEVONO", che può essere riassunta come "meglio avere una buona accidenti motivo per cui no, ed essere in grado di dire quale dannata buona ragione è ") includere una lunghezza (RFC 2616 §14.13) bar alcuni scenari in cui è vietato (§4.4) (in particolare, il valore deve essere sia l'entità e la lunghezza del trasferimento e come tale è valida solo quando la codifica del trasferimento è "identità" [impostazione predefinita]). Non c'è motivo per cui un'intestazione Accept-Ranges non debba essere inviata insieme a una codifica di trasferimento chunked e/o compressa. (Diverso dalla codifica del contenuto compresso, nel qual caso range, come content-length si riferisce alla dimensione compressa).

Alcune cose degne di nota:

  1. Un server può sempre ignorare una richiesta range e rispondere con tutta la lunghezza, anche se aveva suggerito altrimenti. (§ 14.35.2) Quindi, dovresti essere sempre pronto a ricevere questo.
  2. Un server può onorare un Range o If-Range anche se non indicava tramite lo Accept-Ranges. (§14.5)
  3. Un valido Range potrebbe essere ad es. 123- significa "inviami tutto dall'ottetto 123 alla fine." (§14.35.1)
  4. A Range di es. 123-500 è valido anche se la dimensione dell'entità è inferiore a 500, nel qual caso tanti ottetti quanti sono disponibili, tuttavia, non sarebbe valido se ci fossero meno di 123 ottetti nell'intera entità. (§14.35.1)
  5. I valori diversi da bytes sono validi ma non definiti per Accept-Range. (§3.12) significa che il server sta facendo qualcosa di non standard, quindi a meno che non sia menzionato anche lo bytes, dovresti interpretarlo come non compreso uno Accept-Range.
  6. Pur non includendo Content-Length in una risposta incluso Accept-Range è valido, non è molto probabile. Di norma, se dovessi trattare tali risposte come se non avessero incluso un'intestazione Accept-Range, saresti al sicuro da passaggi errati di fronte a tale comportamento, mentre beneficerai anche del comportamento dell'intervallo nella stragrande maggioranza delle volte si avvicinò.
+0

È proprio il punto 4 che mi porta a credere che * richiedo * la lunghezza del contenuto prima di effettuare una richiesta di intervallo. In quale altro modo posso sapere che l'intervallo iniziale '123-' è inferiore alla lunghezza della risorsa? – chowey

+0

Non puoi, anche se non hai già 123 byte e non stai facendo una sorta di download distribuito (che idealmente vorrebbe la lunghezza per le sue ragioni) perché vorresti farlo? Se hai già 123 byte allora deve avere almeno 123 byte. –

+0

Abbastanza giusto. Anche il resto dei tuoi punti è molto utile. – chowey

Problemi correlati