Quantcast

[Django] #28104: Django conditional view processing decorator adds stale ETag

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Django] #28104: Django conditional view processing decorator adds stale ETag

Django
#28104: Django conditional view processing decorator adds stale ETag
-----------------------------------------+------------------------
               Reporter:  safialishah    |          Owner:  nobody
                   Type:  Bug            |         Status:  new
              Component:  Uncategorized  |        Version:  1.11
               Severity:  Normal         |       Keywords:
           Triage Stage:  Unreviewed     |      Has patch:  0
    Needs documentation:  0              |    Needs tests:  0
Patch needs improvement:  0              |  Easy pickings:  1
                  UI/UX:  0              |
-----------------------------------------+------------------------
 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.

--
Ticket URL: <https://code.djangoproject.com/ticket/28104>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups "Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/054.e7c12a187c4a3cf222fc60a0305136f5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Django] #28104: conditional view processing decorator adds stale ETag (was: Django conditional view processing decorator adds stale ETag)

Django
#28104: conditional view processing decorator adds stale ETag
------------------------------------+------------------------------------
     Reporter:  Syed Safi Ali Shah  |                    Owner:  nobody
         Type:  Bug                 |                   Status:  new
    Component:  HTTP handling       |                  Version:  1.11
     Severity:  Normal              |               Resolution:
     Keywords:                      |             Triage Stage:  Accepted
    Has patch:  0                   |      Needs documentation:  0
  Needs tests:  0                   |  Patch needs improvement:  0
Easy pickings:  0                   |                    UI/UX:  0
------------------------------------+------------------------------------
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted
 * component:  Uncategorized => HTTP handling
 * easy:  1 => 0


--
Ticket URL: <https://code.djangoproject.com/ticket/28104#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups "Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/069.a711de260465210acc9940891f2667bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Django] #28104: conditional view processing decorator adds stale ETag

Django
In reply to this post by Django
#28104: conditional view processing decorator adds stale ETag
------------------------------------+------------------------------------
     Reporter:  Syed Safi Ali Shah  |                    Owner:  nobody
         Type:  Bug                 |                   Status:  new
    Component:  HTTP handling       |                  Version:  1.11
     Severity:  Normal              |               Resolution:
     Keywords:                      |             Triage Stage:  Accepted
    Has patch:  0                   |      Needs documentation:  0
  Needs tests:  0                   |  Patch needs improvement:  0
Easy pickings:  0                   |                    UI/UX:  0
------------------------------------+------------------------------------

Comment (by Simon Charette):

 The way conditional decorators are designed will make it hard to implement
 1. which can already be worked around by explicitly setting
 `response['Etag']` in the view once the ressources have been altered.

 I think 2. is the way to go here with documentation mentioning
 `response['Etag']` should be set manually when dealing with unsafe methods
 (e.g. `PUT` conflict).

--
Ticket URL: <https://code.djangoproject.com/ticket/28104#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups "Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/069.54565c405f97636c191e7ef8e5de1d73%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Django] #28104: conditional view processing decorator adds stale ETag

Django
In reply to this post by Django
#28104: conditional view processing decorator adds stale ETag
------------------------------------+------------------------------------
     Reporter:  Syed Safi Ali Shah  |                    Owner:  nobody
         Type:  Bug                 |                   Status:  new
    Component:  HTTP handling       |                  Version:  1.11
     Severity:  Normal              |               Resolution:
     Keywords:                      |             Triage Stage:  Accepted
    Has patch:  0                   |      Needs documentation:  0
  Needs tests:  0                   |  Patch needs improvement:  0
Easy pickings:  0                   |                    UI/UX:  0
------------------------------------+------------------------------------
Changes (by Kevin Christopher Henry):

 * cc: k@… (added)


--
Ticket URL: <https://code.djangoproject.com/ticket/28104#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups "Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-updates/069.d313e886781d5d5a44464821c5681849%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
Loading...