Код состояния HTTP 206: когда его следует использовать?

код состояния 206 (w3.org) указывает частичный результат в ответ на запрос с заголовком Range.

Так что «очевидно», если запрошенный документ, например. 1024 байта, а заголовок Range равен bytes=0-512, тогда должен быть возвращен код состояния 206 Partial Content. (Предполагая, что сервер может вернуть контент)

НО что, если Range равно bytes=0-2000?
Должны ли возвращаться 200 OK или 206 Partial Content?
Мне кажется, что это нечетко определено в спецификации — или, может быть, я читаю не в том месте?

Зачем мне это? Я спрашиваю, потому что Varnish Cache всегда возвращает 206 Partial Content, тогда как отладчик Facebook Open Graph, кажется, ожидает 200 OK. [1] [2]

Пример: запрос GET к Varnish
(я получаю полный документ, но возвращается 206 Partial Content)

> curl --dump-header - -H 'Range: bytes=0-7000' https://www.varnish-cache.org/sites/all/themes/varnish_d7/logo.png
HTTP/1.1 206 Partial Content
Server: nginx/1.1.19
Date: Mon, 14 Apr 2014 22:43:31 GMT
Content-Type: image/png
Content-Length: 2884
Connection: keep-alive
Last-Modified: Thu, 15 Dec 2011 12:30:46 GMT
Accept-Ranges: bytes
X-Varnish: 1979866667
Age: 0
Via: 1.1 varnish
Content-Range: bytes 0-2883/2884

Дополнительная ссылка на w3: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35


person qff    schedule 14.04.2014    source источник


Ответы (1)


Это не имеет значения. Оба ответа действительны.

(также обратите внимание, что текущая спецификация теперь http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-26.html, который скоро будет опубликован как RFC)

person Julian Reschke    schedule 15.04.2014
comment
Но как вы теперь, что это не имеет значения? Мне кажется, что спецификация не ясна по этому поводу, и должна ли она возвращать одно или другое, не определено - дыра в спецификации. - person qff; 15.04.2014
comment
Я знаю, что это не имеет значения, потому что я один из авторов этой спецификации, и если бы это имело значение, мы бы вам сказали. - person Julian Reschke; 15.04.2014
comment
можем ли мы согласиться, что это ошибка в отладчике, тогда - person José F. Romaniello; 03.07.2014