go-goyave / goyave / 34131744451

97%

master: 97%

Pull #295

github

httputil: address review on quality value parsing

Remove qualityValueRegex from util/httputil/httputil.go. Once strconv.ParseFloat has accepted the string and the result is inside the 0 to 1 range, the only thing left to check is the shape RFC 9110 section 12.4.2 allows, so the new isQualityValue counts the characters located after the decimal point and rejects more than three of them.

That helper also rejects any byte that is neither a digit nor the single decimal point, because ParseFloat is more permissive than the regex it replaces. ParseFloat accepts "1e-2", "+0.5", "0x1p-1" and "NaN", and the range comparison lets NaN through since every comparison against NaN is false. The "scientific_notation" case in util/httputil/httputil_test.go expects "gzip;q=1e-2" to have a priority of 0, so the digit check keeps everything the regex rejected rejected, in the same loop and without a second number parser.

Merge TestParseMultiValuesHeaderQualityValue into TestParseMultiValuesHeader in util/httputil/httputil_test.go. There is now one table driven test instead of a table plus a list of bare assertions, and the eight assertions of the old test are named cases like the rest.

Add the "negative_quality_value" case, "gzip;q=-0.5, br;q=0.1", where the negative value gets a priority of 0 and sorts behind br.

Add the "whitespace_around_quality_value" case, "gzip;q= 0.9, br;q=0.8 , bz;q = 0.7 ", which gives 0.9, 0.8 and 0.7. Both the parameter name and the parameter value are trimmed in parseQuality, so a space after "q=" and spaces around the "=" do not change the quality value.

Document the parsing in ParseMultiValuesHeader with the RFC 9110 section 12.4.2 reference, with what is trimmed exactly (the whole input, each value, and the name and the value of the "q" parameter), and with the fact that parameters other than "q" such as "charset" are accepted, ignored for the priority and left out of the returned value, which only holds what is located before the first ";".

24 of 24 new or added lines in 1 file covered. (100.0%)

5674 of 5841 relevant lines covered (97.14%)

273.57 hits per line