* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #507 (closed design: incorporated)

Opened 14 months ago

Last modified 14 months ago

integer value parsing

Reported by: julian.reschke@gmx.de Owned by:
Priority: normal Milestone: 25
Component: non-specific Severity: In IETF LC
Keywords: Cc:
Origin:

Description (last modified by julian.reschke@gmx.de) (diff)

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)

Attachments

507.diff (1.9 KB) - added by julian.reschke@gmx.de 14 months ago.
Proposed patch

Change History

comment:1 Changed 14 months ago by julian.reschke@gmx.de

  • Severity changed from In WG Last Call to In IETF LC

comment:2 Changed 14 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:3 Changed 14 months ago by julian.reschke@gmx.de

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:4 Changed 14 months ago by julian.reschke@gmx.de

  • Milestone changed from unassigned to 25

comment:5 Changed 14 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution wontfix deleted

comment:6 Changed 14 months ago by julian.reschke@gmx.de

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

Changed 14 months ago by julian.reschke@gmx.de

Proposed patch

comment:7 Changed 14 months ago by julian.reschke@gmx.de

From [2480]:

clarify integer parsing requirement (see #507)

comment:8 Changed 14 months ago by julian.reschke@gmx.de

  • Status changed from reopened to closed
  • Resolution set to incorporated
Note: See TracTickets for help on using tickets.