search

httpwg / httpbis-issues

1 stars 1 forks source link

integer value parsing #507

Closed mnot closed 3 years ago

mnot commented 10 years ago

P1, Content-Length:

Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of a payload, a recipient SHOULD anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (Section 9.3).

P5, Byte-Ranges:

In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.

So we have similar text, once with "SHOULD", once with "ought to". We should make this consistent. Also, why isn't this a MUST?

(thanks to SM for spotting this)

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

mnot commented 10 years ago

julian.reschke@gmx.de changed severity from In WG Last Call to In IETF LC

mnot commented 10 years ago

julian.reschke@gmx.de changed description from:

P1, Content-Length:

Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of a payload, a recipient SHOULD anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (Section 9.3).

P5, Byte-Ranges:

In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.

So we have similar text, once with "SHOULD", once with "ought to". We should make this consistent. Also, why isn't this a MUST?

(thanks to SM for spotting this)

to:

P1, Content-Length:

Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of a payload, a recipient SHOULD anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (Section 9.3).

P5, Byte-Ranges:

In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.

So we have similar text, once with "SHOULD", once with "ought to". We should make this consistent. Also, why isn't this a MUST?

(thanks to SM for spotting this)

mnot commented 10 years ago

In P1, failure to properly parse C-L implies broken message framing.

In P5, it's just metadata on the message, and failure to process it has no effect on anything after that message. That's why it's not as important as in P1.

mnot commented 10 years ago

julian.reschke@gmx.de changed milestone from unassigned to 25

mnot commented 10 years ago
mnot commented 10 years ago

julian.reschke@gmx.de commented:

From http://svn.tools.ietf.org/svn/wg/httpbis/wg_materials/ietf88/minutes.txt:

507 SHOULD vs ought to on integer parsing

Julian recorded this as a design issue because this hadn't be considered.

Roy is OK with MUST on the content-length, that's a framing issue. p5 is different because it is an optional feature and if this fails, the thing breaks.

Barry is concerned that even for an optional feature, this needs to be defined so that it can work. He is also concerned about this turning into a security problem (integer overflow, etc...)

Mark: describes a cached 206 and the potential consequences of overflow in that case. Agreement that this might cause corruption.

Roy: OK with MUST

mnot commented 10 years ago

Proposed patch

mnot commented 10 years ago

julian.reschke@gmx.de commented:

From 2480:

clarify integer parsing requirement (see #507)

mnot commented 10 years ago