Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#28690 closed Bug (fixed)

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

Reported by: Mads Jensen Owned by: Ad Timmering
Component: Utilities Version: dev
Severity: Normal Keywords:
Cc: Ad Timmering Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description (last modified by Ad Timmering)

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.

Attachments (1)

parse-http-date-year.patch (2.1 KB ) - added by Mads Jensen 7 years ago.

Download all attachments as: .zip

Change History (29)

by Mads Jensen, 7 years ago

Attachment: parse-http-date-year.patch added

comment:1 by Claude Paroz, 7 years ago

Component: UncategorizedUtilities
Triage Stage: UnreviewedAccepted

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.

comment:2 by Alexander Vyushkov, 7 years ago

Owner: changed from nobody to Alexander Vyushkov
Status: newassigned

comment:3 by Alexander Vyushkov, 7 years ago

Has patch: set

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

comment:4 by Levi Payne, 7 years ago

Triage Stage: AcceptedReady for checkin

comment:5 by Levi Payne, 7 years ago

Triage Stage: Ready for checkinAccepted

Still some suggested edits on the PR.

comment:6 by Tim Graham, 7 years ago

Patch needs improvement: set

comment:7 by Alexander Vyushkov, 7 years ago

Patch needs improvement: unset

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?

comment:8 by Tim Graham, 7 years ago

Patch needs improvement: set

comment:9 by Alexander Vyushkov, 7 years ago

Patch needs improvement: unset

sent new pull request

comment:10 by Carlton Gibson, 7 years ago

Patch needs improvement: set

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

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

comment:11 by Tameesh Biswas, 6 years ago

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

Last edited 6 years ago by Tameesh Biswas (previous) (diff)

comment:12 by Alexander Vyushkov, 6 years ago

Owner: Alexander Vyushkov removed
Status: assignednew

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

comment:13 by Tameesh Biswas, 6 years ago

Owner: set to Tameesh Biswas
Status: newassigned

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

Last edited 6 years ago by Tameesh Biswas (previous) (diff)

comment:14 by Vishvajit Pathak, 6 years ago

Tameesh Biswas

Are you working on this ?

comment:15 by Tameesh Biswas, 6 years ago

Yes, I am.

comment:16 by Tameesh Biswas, 6 years ago

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?

comment:17 by Simon Charette, 6 years ago

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

comment:18 by David Jovanović, 5 years ago

Owner: changed from Tameesh Biswas to David Jovanović

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

comment:20 by David Jovanović, 5 years ago

Patch needs improvement: unset

comment:21 by Tim Bell, 5 years ago

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.

comment:22 by Tim Bell, 5 years ago

Patch needs improvement: set

comment:23 by Ad Timmering, 5 years ago

Cc: Ad Timmering added
Description: modified (diff)
Owner: changed from David Jovanović to 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
Version 1, edited 5 years ago by Ad Timmering (previous) (next) (diff)

comment:24 by Ad Timmering, 5 years ago

Patch needs improvement: unset

comment:25 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

In 7cbd25a:

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

comment:26 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

Resolution: fixed
Status: assignedclosed

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.

comment:27 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

In f38655e:

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

Backport of 7cbd25a06e820cbd1a0bfbc339fb7d9a737c54fa from master

comment:28 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

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

Note: See TracTickets for help on using tickets.
Back to Top