RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (2)

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Source of RFC: httpbis (app)

Errata ID: 4664

Status: Verified
Type: Technical

Reported By: Amichai Rothman
Date Reported: 2016-04-13
Verifier Name: Alexey Melnikov
Date Verified: 2017-02-23

Section 4.4 says:

The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 3.1) overlap
the current extent of the selected resource or that the set of ranges
requested has been rejected due to invalid ranges or an excessive
request of small or overlapping ranges.

It should say:

The 416 (Range Not Satisfiable) status code indicates that none of
the ranges in the request's Range header field (Section 3.1) overlap
the current extent of the selected representation or that the set of
ranges requested has been rejected due to invalid ranges or an excessive
request of small or overlapping ranges.

Notes:

The overlap may depend on the representation, not only the resource, as is the case with byte ranges.

Errata ID: 4707

Status: Verified
Type: Editorial

Reported By: Julian Reschke
Date Reported: 2016-06-09
Verifier Name: Alexey Melnikov
Date Verified: 2016-06-10

Section Appendix C says:

The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character).

It should say:

The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CHAR (single character),
CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character).

Notes:

CHAR is used in Section 4.2 but not mentioned here.

Status: Held for Document Update (1)

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Source of RFC: httpbis (app)

Errata ID: 4358

Status: Held for Document Update
Type: Editorial

Reported By: Tim
Date Reported: 2015-05-07
Held for Document Update by: Barry Leiba
Date Held: 2015-05-12

Section 4 says:

The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1).

It should say:

The 206 (Partial Content) status code indicates that the server is
successfully fulfilling a range request for the target resource by
transferring one or more parts of the selected representation that
correspond to the satisfiable ranges found in the request's Range
header field (Section 3.1). A response may chose to satisfy only
part of a requested range.

Notes:

Firefox and Chrome already behave as if the "Corrected Text"
statement is true.

It may be desirable if for example a user returns to a
html5 video with auto play, pauses the video and is only
interested in responding to a comment on the page. In this example
it would be unnecessarily costly to transfer the whole 128GB when
the user only consumes a few MB.

Alternative: maybe it should only be true if last-byte-pos is
absent.

----- Verifier Notes -----
The reporter is uncertain of the meaning and asks that it be clarified, one way or the other. A future update of the document might consider clarifying wording.

Status: Rejected (5)

RFC 7233, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", June 2014

Source of RFC: httpbis (app)

Errata ID: 4391

Status: Rejected
Type: Technical

Reported By: Nathan Herring
Date Reported: 2015-06-11
Rejected by: Barry Leiba
Date Rejected: 2015-06-11

Section 2.1 says:

   If a valid byte-range-set includes at least one byte-range-spec with
   a first-byte-pos that is less than the current length of the
   representation, or at least one suffix-byte-range-spec with a
   non-zero suffix-length, then the byte-range-set is satisfiable.
   Otherwise, the byte-range-set is unsatisfiable.

It should say:

   If a valid byte-range-set includes at least one byte-range-spec with
   a first-byte-pos that is less than the current length of the
   representation, or at least one suffix-byte-range-spec with a
   non-zero suffix-length and the current length of the representation
   is non-zero, then the byte-range-set is satisfiable. Otherwise, the
   byte-range-set is unsatisfiable.

Notes:

Asking for a range that includes trailing bytes (e.g., Range: bytes=-1) when the entity is zero bytes is, as stated here, satisfiable, and yet the service would be forced to yield a 206 code and there is no valid representation of Content-Range header, since you cannot specify a range with no length using the byte range type, the none range type is specified in section 2.3 with a meaning for Accept-Ranges only, and there are no other acceptable ranges in the IANA registry.

The alternative would be that we could overload the use of the none range and return 206 with Content-Length: 0, Content-Range: none for these requests for final bytes.
--VERIFIER NOTES--
It also says, in the same section:

If the selected representation is shorter than the specified
suffix-length, the entire representation is used.

So the response for the posited request is 200 (not 206).

Errata ID: 4472

Status: Rejected
Type: Technical

Reported By: Florian Best
Date Reported: 2015-09-13
Rejected by: Barry Leiba
Date Rejected: 2015-09-29

Section 2.1 says:

   o  The first and last bytes only (bytes 0 and 9999):

        bytes=0-0,-1

It should say:

   o  The first and last bytes only (bytes 0 and 9999):

        bytes=0-1,-1

Notes:

If the first byte is requested the offset must be 1.
--VERIFIER NOTES--
The reporter has retracted this after more testing, saying that "The sentence 'the byte positions specified are inclusive' seems to explain it," though he thinks it could be explained more clearly and directly.

Errata ID: 4665

Status: Rejected
Type: Technical

Reported By: Amichai Rothman
Date Reported: 2016-04-13
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 3.1 says:


It should say:

If all of the preconditions are true and the target representation
length is zero, the server SHOULD send a 200 (OK) response.

Notes:

An empty representation is unsatisfiable according to section 2.1, but not unsatisfiable according to section 4.4 if the first-byte-pos is zero. An empty 200 response is the simplest solution to this contradiction, since it is a valid response anyway (if the server chooses to ignore the Range header), clients already handle it properly, it provides all necessary information to the client, and stating it explicitly can prevent subtle edge-case pitfalls in both the RFC and its implementations.
--VERIFIER NOTES--
Mark Nottingham: this is not an erratum. Please raise an issue here:
<https://github.com/httpwg/http11bis/issues>

Errata ID: 4681

Status: Rejected
Type: Technical

Reported By: Kannan Goundan
Date Reported: 2016-04-29
Rejected by: Alexey Melnikov
Date Rejected: 2016-05-05

Section 2.1 says:

byte-range-set  = 1#( byte-range-spec / suffix-byte-range-spec )

It should say:

byte-range-set = *( "," OWS ) ( byte-range-spec /
    suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
    suffix-byte-range-spec ) ] )

Notes:

The document contains two ABNF definitions for "byte-range-set". They appear in Section 2.1 "Byte Ranges" and Appendix D "Collected ABNF".

The two definitions are different. It seems like the definition in Appendix D is the correct one.
--VERIFIER NOTES--
Alexey: As per comment from Julian: "Both are correct. See first sentence of Appendix D."

Errata ID: 4682

Status: Rejected
Type: Technical

Reported By: Kannan Goundan
Date Reported: 2016-05-03
Rejected by: Alexey Melnikov
Date Rejected: 2017-02-23

Section 2.1 says:

byte-range-set= 1#( byte-range-spec / suffix-byte-range-spec )

It should say:

According to the "1#element" rule, the expansion would be:

    byte-range-set = ( byte-range-spec /
        suffix-byte-range-spec ) *( OWS "," OWS ( byte-range-spec /
        suffix-byte-range-spec ) )

But Appendix D has the definition:

    byte-range-set = *( "," OWS ) ( byte-range-spec /
        suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
        suffix-byte-range-spec ) ] )

Notes:

This is a followup to my original report: <http://www.rfc-editor.org/errata_search.php?rfc=7233&eid=4681>

My original report was incorrect because I didn't notice the difference between "1*element" and "1#element". Thanks to Julian Reschke for pointing this out to me.

After looking up the "1#element" rule <https://tools.ietf.org/html/rfc7230#section-7>, it looks like Section 2.1 and Appendix D are more similar, but not exactly equivalent.

The Appendix D version of the rule seems to allow extra commas and OWS.
I'm trying to write strict parsing code for this header and am not sure which definition to follow.

P.S. I hope I didn't screw up again. I apologize for wasting your time (again) if I did.
--VERIFIER NOTES--
See HTTPBIS mailing list discussion.

Report New Errata



Search RFCs
Advanced Search
×