search

httpwg / httpbis-issues

1 stars 1 forks source link

IESG ballot on draft-ietf-httpbis-p5-range-25 #534

Closed mnot closed 3 years ago

mnot commented 10 years ago

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

''The point of the prose is not to repeat the ABNF, but to provide additional information. I'm not saying that we can't make this change, but I fear that if we want to do this consistently, we'd have to do this in many more places.''

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date is never a valid entity-tag because the former doesn't allow DQUOTE and the latter requires DQUOTEs.''

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/534

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored.

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?
mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?
mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?
mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

  • 3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that?

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date never is a valid entity-tag''

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date never is a valid entity-tag''

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

''The point of the prose is not to repeat the ABNF, but to provide additional information. I'm not saying that we can't make this change, but I fear that if we want to do this consistently, we'd have to do this in many more places.''

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date never is a valid entity-tag''

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

''The point of the prose is not to repeat the ABNF, but to provide additional information. I'm not saying that we can't make this change, but I fear that if we want to do this consistently, we'd have to do this in many more places.''

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date never is a valid entity-tag''

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

''Not sure why we would to call out If-Unmodified-Since (as opposed to If-Modified-Since), or dates as opposed to entity tags; I believe the text as it is is fine''

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar? -- ''yes, that sure is possible, but does that merit a special security consideration???''

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

''The point of the prose is not to repeat the ABNF, but to provide additional information. I'm not saying that we can't make this change, but I fear that if we want to do this consistently, we'd have to do this in many more places.''

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date never is a valid entity-tag''

mnot commented 10 years ago
mnot commented 10 years ago

fielding@gbiv.com commented:

From 2559:

(editorial) clarify that If-Range uses an exact match comparison even for HTTP-date, unlike If-Unmodified-Since; see #534 comment from Richard Barnes

mnot commented 10 years ago

fielding@gbiv.com changed description from:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

''Not sure why we would to call out If-Unmodified-Since (as opposed to If-Modified-Since), or dates as opposed to entity tags; I believe the text as it is is fine''

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar? -- ''yes, that sure is possible, but does that merit a special security consideration???''

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

''The point of the prose is not to repeat the ABNF, but to provide additional information. I'm not saying that we can't make this change, but I fear that if we want to do this consistently, we'd have to do this in many more places.''

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date never is a valid entity-tag''

to:

Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."

  • '''That would be incorrect. As stated in the last paragraph, the comparison function is an exact match. I have clarified that by explicitly noting how it is unlike If-Unmodified-Since. See 2559.'''

COMMENT 2: In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

  • '''Not if implemented according to the specification. Section 2.1 (Byte Ranges) defines that case as follows:'''

    A client can limit the number of bytes requested without knowing the size of the selected representation. If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range is interpreted as the remainder of the representation (i.e., the server replaces the value of last-byte-pos with a value that is one less than the current length of the selected representation).

Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- ''see #537''

0) Abstract: Maybe would add stateless in front of protocol in the description. -- ''see #538''

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte positions specified are inclusive.

''The point of the prose is not to repeat the ABNF, but to provide additional information. I'm not saying that we can't make this change, but I fear that if we want to do this consistently, we'd have to do this in many more places.''

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none". -- ''done as part of #526''

Stephen Farrell

Comment (2013-12-18)

3.2: Is an HTTP-date value a valid value for an entity-tag? If so, I assume that an If-Range value is interpreted as a date. Do you need to say that? -- ''an HTTP-date is never a valid entity-tag because the former doesn't allow DQUOTE and the latter requires DQUOTEs.''