django.utils.http.parse_http_date two digit year check is incorrect

[Mads Jensen]

RFC 850 does not mention this, but in RFC 7231 (and there's something similar in RFC 2822), there's the following quote:

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.

Current logic is hard coded to consider 0-69 to be in 2000-2069, and 70-99 to be 1970-1999, instead of comparing versus the current year.

[Claude Paroz]

Accepted, however I don't think your patch is correct. The check should be relative to the current year, if I read the RFC quote correctly.

[Alexander Vyushkov]

Created a pull request: Created a pull request: ​https://github.com/django/django/pull/9214

[Levi Payne]

Still some suggested edits on the PR.

[Alexander Vyushkov]

I added regression test that fails with old code (test_parsing_rfc850_year_69), updated commit message to hopefully follow the guidelines, and added additional comments about the change. Squashed commits as well.
Could you review the pull request again?

[Alexander Vyushkov]

sent new pull request

[Carlton Gibson]

This is awaiting for changes from Tim's feedback on PR.

(Please uncheck "Patch needs improvement" again when that's done. 🙂)

[Tameesh Biswas]

As this issue hasn't received any updates in the last 8 months, may I work on this ticket?

[Alexander Vyushkov]

Go for it, I don't think I will have time to finish it.

[Tameesh Biswas]

Thanks, I'll pick up from where you left off in the PR and make the recommended changes on a new PR.

[Vishvajit Pathak]

Tameesh Biswas

Are you working on this ?

[Tameesh Biswas]

Yes, I am.

[Tameesh Biswas]

I've just picked up from the previous PR and opened a new PR here: ​https://github.com/django/django/pull/10749
It adds regression tests in the first commit that pass without applying the fix and adds the fix with another test-case that only passes with the fix applied.
Could you please review the changes?

[Simon Charette]

Tameesh, I left a comment on the PR regarding the use of non-UTC today.

[David Jovanović]

As an issue haven't received an update for 4 months, I'm taking it over (djangocon europe 2019 sprint day 1).

[David Jovanović]

Created new PR: ​https://github.com/django/django/pull/11212

[Tim Bell]

I think an earlier comment by Simon Charette (about using a fixed year in the tests) still applies to the new PR; I've added it.

[Ad Timmering]

Taking the liberty to reassign due to inactivity (6 months) and adding a pull request with revised code and addressing feedback on prior PRs. Please add give your comments for any concerns:)

PR => ​https://github.com/django/django/pull/11848

• Year is now checked in relation to current year, rolling over to the past if more than 50 years in the future
• Test now uses a patched version of datetime.datetime to pin to a specific year and have static test cases

[Mariusz Felisiak <felisiak.mariusz@…>]

In 7cbd25a:

Refs #28690 -- Added more tests for parse_http_date().

[Mariusz Felisiak <felisiak.mariusz@…>]

In 7b5f8ac:

Fixed #28690 -- Fixed handling of two-digit years in parse_http_date().

Due to RFC7231 ayear that appears to be more than 50 years in the
future are interpreted as representing the past.

[Mariusz Felisiak <felisiak.mariusz@…>]

In f38655e:

[3.0.x] Refs #28690 -- Added more tests for parse_http_date().

Backport of 7cbd25a06e820cbd1a0bfbc339fb7d9a737c54fa from master

[Mariusz Felisiak <felisiak.mariusz@…>]

In 556d0c0:

[3.0.x] Fixed #28690 -- Fixed handling of two-digit years in parse_http_date().

Due to RFC7231 ayear that appears to be more than 50 years in the
future are interpreted as representing the past.

Backport of 7b5f8acb9e6395a1660dd7bfeb365866ca8ef47c from master