RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 10 records.

Status: Verified (3)

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

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4664
Status: Verified
Type: Technical
Publication Format(s) : TEXT

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: 5474
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Kalin Gyokov
Date Reported: 2018-08-21
Verifier Name: Alexey Melnikov
Date Verified: 2018-09-04

Section 4.4. says:

For byte ranges, failing to overlap the current extent means that the
   first-byte-pos of all of the byte-range-spec values were greater than
   the current length of the selected representation.

It should say:

For byte ranges, failing to overlap the current extent means that the
   first-byte-pos of all of the byte-range-spec values were greater than
   or equal to the current length of the selected representation.
   ^^^^^^^^^^^

Notes:

If the length of the representation is 500 bytes, then the range of the entire representation is 0-499. Then a range starting at byte position 500 fails to overlap the representation.

Errata ID: 4707
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

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 (2)

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

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 5620
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Armin Abfalterer
Date Reported: 2019-02-01
Held for Document Update by: Barry Leiba
Date Held: 2020-11-13

Section 4.2 says:

Content-Range       = byte-content-range
                    / other-content-range

other-content-range = other-range-unit SP other-range-resp
other-range-resp    = *CHAR

Notes:

Due to the loose definition of "other-content-range" invalid "byte content range" values are possible.

For example, following invalid header value is not valid according to "byte-content-range" (as "complete-length" or "*" is missing) but is yet allowed by "other-content-range".

Content-Range: bytes 42-1233/

The problem might be solved by excluding "bytes-unit" in "other-range-unit".

Errata ID: 4358
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

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

Note: This RFC has been obsoleted by RFC 9110

Source of RFC: httpbis (wit)

Errata ID: 4391
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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
Publication Format(s) : TEXT

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



Advanced Search