Opened 8 years ago

Closed 8 years ago

#27545 closed Bug (wontfix)

Django conditional If-Match: * returns precondition failed response

Reported by: David Harrigan Owned by: nobody
Component: HTTP handling Version: 1.10
Severity: Normal Keywords: precondition, etags, etag, if-match
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I believe there is a small bug in how If-Match: * behavior is supposed to work in Django version <= 1.10. I know that 1.11 is migrating to RFC-7232 specification conditional header, and that version <= 1.10 implements according to RFC-2616.

Expected behavior of If-Match: * according to RFC-2616:

If any of the entity tags match the entity tag of the entity that
would have been returned in the response to a similar GET request
(without the If-Match header) on that resource, or if "*" is given
and any current entity exists for that resource, then the server MAY
perform the requested method as if the If-Match header field did not
exist.

So if * is given as the field-value, Django should allow the process to continue as long as the entity exits.

Current behavior: https://github.com/django/django/blob/1.10.3/django/utils/cache.py#L184

Where etag variable is the etag for the entity in question.

# returns precondition failed if this evaluates to true
(not etag and '*' in etags) or (etag and etag not in etags) 

Problem: * in etags not considered here if etag is present. According to the RFC, as long as the entity is present on the server, If-Match: * should yield in as If-Match header was not given by the client. This scenario here in Django implementation results in precondition failed.

I believe the above code should be re-written as something like:

not etag or                                          # not etag == no entity, so always return a 412
not ('*' in etags or etag in etags)    # allow * in etags or client specified etag in etags

Change History (3)

comment:1 by Tim Graham, 8 years ago

Unless the issue is a regression from an older version of Django, it's unlikely to qualify for a fix on the 1.10 branch. See our support versions policy.

in reply to:  1 comment:2 by David Harrigan, 8 years ago

Replying to Tim Graham:

Unless the issue is a regression from an older version of Django, it's unlikely to qualify for a fix on the 1.10 branch. See our support versions policy.

Yes, I believe this behavior exists for version 1.8.x (LTS) and 1.9.x. I can prepare a patch for these branches if this issue qualifies for a fix?

comment:3 by Tim Graham, 8 years ago

Resolution: wontfix
Status: newclosed

It's not clear to me that this is a critical issue that qualifies for a backport. As described in the supported versions policy, 1.9 and 1.8 are only receiving fixes for security and data loss issues.

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