id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
28104	conditional view processing decorator adds stale ETag	Syed Safi Ali Shah	nobody	"For conditional view processing, Django provides the @condition decorator, which is defined here https://github.com/django/django/blob/master/django/views/decorators/http.py

While it works nicely for GET requests, it has a bug when handling unsafe methods such as PUT or PATCH that modify a resource.
If the PUT or PATCH request contains a valid ETag in the If-Match header, the request is allowed to go through to the view for processing. Once processed, the resource would have been modified, which would most likely cause the ETag to be updated.

However, the @condition decorator would simply add the ETag that it had computed *before* the request was processed, into the PUT or PATCH response. By now this ETag is not valid anymore. Same would apply to the Last-Modified header.

Below is the snippet of the buggy code:-
{{{
#!div style=""font-size: 80%""
  {{{#!python
            # Set relevant headers on the response if they don't already exist.
            if res_last_modified and not response.has_header('Last-Modified'):
                response['Last-Modified'] = http_date(res_last_modified)  # possibly stale value
            if res_etag and not response.has_header('ETag'):
                response['ETag'] = res_etag  # possible stale value
  }}}
}}}

There are two solutions:
1) If the request was for an unsafe method, re-compute the ETag before sending the response back.
or
2) As pointed out by Kevin [http://stackoverflow.com/questions/43495112/django-conditional-view-processing-decorator-adds-stale-etag here], to comform to the RFC better, we should avoid sending ETag and Last-Modified headers in response to unsafe methods.

"	Bug	closed	HTTP handling	1.11	Normal	fixed		k@… josh.schneier@…	Accepted	1	0	0	0	0	0