Unclear handling of out-of-range values for HTTP API for Save-Impression

[apasel422]

The Save-Impression HTTP API has four structured-header integer keys, with the corresponding WebIDL types:

Key	WebIDL type
histogram-index	unsigned long
match-value	unsigned long
priority	long
lifetime-days	unsigned long

WebIDL's unsigned long is a 32-bit unsigned integer (maximum 4,294,967,295); its long is a 32-bit signed integer (minimum -2,147,483,648, maximum 2,147,483,647). Structured-header integers have the range -999,999,999,999,999 to 999,999,999,999,999 inclusive (15 digits), exceeding the 32-bit range for both signed and unsigned.

As a result, we need to more precisely specify how the structured-header integers are converted into WebIDL values. In general, the two ways to address this are silent clamping and rejection, which could also be applied on a per-key basis:

The WebIDL histogramIndex field is already rejected if it exceeds the implementation-defined maximum histogram size, so we could similarly reject out-of-range histogram-index HTTP values. This field cannot be clamped, as the histogram index has critical semantic implications for proper interpretation of any resulting report.

The WebIDL matchValue field has no additional requirements beyond unsigned long. We could reject match-value HTTP values outside the unsigned long range. This field cannot be clamped, as matchValue and matchValues (from the conversion side) are compared using equality, meaning that erroneous comparisons could occur with clamping. In other words, despite being integers, these fields are really opaque identifiers.

The WebIDL priority field has no additional requirements beyond long. We could reject priority HTTP values outside the long range. This field probably shouldn't be clamped, as it could allow a lower-priority impression to be selected over a higher-priority one when both are clamped.

The WebIDL lifetimeDays field is already clamped to the user agent's upper limit, so we could likewise clamp the lifetime-days HTTP value to the unsigned long range, after which it will be subject to additional clamping based on that upper limit.

Taken together, the existing handling of these fields in the HTTP-parsing algorithm mostly just works, but we should be explicit about these conversions so there is no ambiguity about how they are handled.