django conditional view processing decorator issue

[Safi Ali]

Hi,

I have been trying to use the django conditional view processing feature. Basically I want to deny update operations on an entity if it has since been modified by another user, and that seems to work well with the @condition decorator provided by django.

However there is one issue which I noticed while testing it and later I checked in the django sources and I found what I think could be a bug, but just wanted to confirm here first before submitting a bug report and a fix.

The decorator is called when a new request comes in, it first calculates the etag and last_modified timestamp based on the functions passed in to the decorator, then it passes control over to the get_conditional_response() function. Here the etag and last_modified verification would be performed and if they dont match to whats provided in the request, the request will be denied. so far so good.

If the checks pass, the request is allowed and the view is called to process the request and generate the response. While processing the request, if it was an unsafe method e.g. PUT or PATCH, it would update the entity, which would most likely change the etag and last_modified values.

However, I noticed that a successful response to PUT or PATCH is sent back with the etag or last_modified timestamp calculated *before* the update was actually performed, and by now these etag/last_modified values are invalid or stale. This to me seems wrong. Doing a fresh GET on the same entity then provides the user with updated etag/last_modified values in the response. 

Dont you think, the codition decorator should check if the request method is unsafe, then it should do a fresh calculation of etag/last_modified after the view processing, and then add the fresh values to the response?

Regards,

Safi