Django conditional If-Match: * returns precondition failed response

[David Harrigan]

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

[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.

[David Harrigan]

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?

[Tim Graham]

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.