#15144: Max age set in cache control no longer obeys timeout set with 
@cache_page
decorator
-----------------------------------+----------------------------------------
          Reporter:  jsdalton      |         Owner:  nobody             
            Status:  new           |     Milestone:  1.3                
         Component:  Cache system  |       Version:  SVN                
        Resolution:                |      Keywords:  blocker, regression
             Stage:  Unreviewed    |     Has_patch:  0                  
        Needs_docs:  0             |   Needs_tests:  0                  
Needs_better_patch:  0             |  
-----------------------------------+----------------------------------------
Comment (by jsdalton):

 Thanks Russ. I uploaded a patch which, for me anyway, produces a failure
 in the test suite demonstrating the regression.

 Basically, in these tests I add an additional view that sets an explicit
 cache_timeout of 4 seconds. I hit the view once along with the other tests
 to get it in the cache. After the 2 second sleep, my view with a 4-second
 timeout should still be hitting the cache. However, it does not, since
 it's using the timeout value of 1 that was put in when the 'other' cache
 is set up for the tests.

 Also, if you look at the value of the Cache-Control header after the first
 hit on my view, e.g. if you do:

 {{{
         # Request from the alternate cache with a new prefix and a custom
 timeout
         response = other_with_timeout_view(request, '20')
         self.assertEquals(response.content, 'Hello World 20')
         print response['Cache-Control']
 }}}

 It'll print "max-age=1" instead of 4, which is the value passed to the
 view in the decorator.

 I agree with you, something funky is going on, because self.cache_timeout
 = self.cache.default_timeout *should* work, but at least for me it
 doesn't. I'll observe that a trivial fix is self.cache_timeout =
 cache_timeout or self.cache.default_timeout. This does fix the problem,
 but I'm not sure it's the right answer because I think there is some other
 stuff that needs to be sorted out properly in __init__.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/15144#comment:2>
Django <http://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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to