Subject: #271: SHOULD review in p5

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jun 2012 11:44:14 +1000

As per <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/271>, I'm reviewing our use of SHOULD in the documents. Where I find issues, I've flagged with EDITORIAL or DESIGN as seems appropriate (I won't open issues for the design ones until we discuss; the editorial ones are considered attached to #271).

2.

"If a range unit is not understood in a request, a server MUST ignore the whole Range header field (Section 5.4). If a range unit is not understood in a response, an intermediary SHOULD pass the response to the client; a client MUST fail."

OK.

3.1

"If a 206 is sent in response to a request with an If-Range header field, it SHOULD NOT include other representation header fields."

OK

3.2

"A server SHOULD return a response with this status code if a request included a Range header field (Section 5.4), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range header field (Section 5.3)."

OK

"When this status code is returned for a byte-range request, the response SHOULD include a Content-Range header field specifying the current length of the representation (see Section 5.2)."

OK

4.1

"When a client asks for multiple ranges in one request, the server SHOULD return them in the order that they appeared in the request."

OK

5.2

"The header field SHOULD indicate the total length of the full representation, unless this length is unknown or difficult to determine."

OK

"In the case of a byte range request: A server sending a response with status code 416 (Requested range not satisfiable) SHOULD include a Content-Range field with a byte-range-resp-spec of "*"."

OK

"If the server ignores a byte-range-spec (for example if it is syntactically invalid, or if it may be seen as a denial-of-service attack), the server SHOULD treat the request as if the invalid Range header field did not exist."

EDITORIAL - "may" -> "might"

5.3

"The If-Range header field SHOULD only be sent by clients together with a Range header field."

OK

"If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server SHOULD send the specified sub-range of the representation using a 206 (Partial Content) response. If the validator does not match, then the server SHOULD send the entire representation using a 200 (OK) response."

OK

5.4.1

"Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server SHOULD return a response with a 416 (Requested range not satisfiable) status code. Otherwise, the server SHOULD return a response with a 206 (Partial Content) status code containing the satisfiable ranges of the representation."

OK.

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Sat, 23 Jun 2012 12:46:57 +0200

On 2012-06-22 03:44, Mark Nottingham wrote:
> ...
> ...

Already fixed in 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1685#file7>.

Best regards, Julian