Package: http_parser
Description
parseHttpDate() supports obsolete RFC 850 HTTP-date values, but it interprets the two-digit year as 1900 + yy unconditionally.
That does not match the HTTP-date recipient rule for rfc850-date. RFC 9110 Section 5.6.7 says:
Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits.
Reference: https://www.rfc-editor.org/rfc/rfc9110.html#section-5.6.7
Reproduction
With http_parser 4.1.2:
import 'package:http_parser/http_parser.dart';
void main() {
print(parseHttpDate('Sunday, 21-Jun-26 07:28:00 GMT').toUtc());
}
Actual behavior
The value is parsed as year 1926, because the implementation currently does:
final year = 1900 + _parseInt(scanner, 2);
Current source on master:
https://github.com/dart-lang/http/blob/master/pkgs/http_parser/lib/src/http_date.dart#L71
Expected behavior
When parsed in 2026, Sunday, 21-Jun-26 07:28:00 GMT should resolve to 2026-06-21T07:28:00Z, not 1926.
More generally, rfc850-date two-digit years need to be resolved using the RFC 9110 50-year rule rather than a fixed 1900 + yy mapping.
Impact
Downstream HTTP clients that rely on parseHttpDate() for fields such as Retry-After can treat a future RFC 850 timestamp as a past timestamp and retry immediately.
Package:
http_parserDescription
parseHttpDate()supports obsolete RFC 850 HTTP-date values, but it interprets the two-digit year as1900 + yyunconditionally.That does not match the HTTP-date recipient rule for
rfc850-date. RFC 9110 Section 5.6.7 says:Reference: https://www.rfc-editor.org/rfc/rfc9110.html#section-5.6.7
Reproduction
With
http_parser4.1.2:Actual behavior
The value is parsed as year 1926, because the implementation currently does:
Current source on
master:https://github.com/dart-lang/http/blob/master/pkgs/http_parser/lib/src/http_date.dart#L71
Expected behavior
When parsed in 2026,
Sunday, 21-Jun-26 07:28:00 GMTshould resolve to2026-06-21T07:28:00Z, not 1926.More generally,
rfc850-datetwo-digit years need to be resolved using the RFC 9110 50-year rule rather than a fixed1900 + yymapping.Impact
Downstream HTTP clients that rely on
parseHttpDate()for fields such asRetry-Aftercan treat a future RFC 850 timestamp as a past timestamp and retry immediately.