On Friday 31 March 2006 18:57, Luke Plant wrote:
> So the issue here is entirely to do with an intermediate web cache,
> and from what I can tell
> ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13 ), the
> cache is behaving itself perfectly well - since the page had no
> 'Expires' h
On Friday 31 March 2006 18:51, oggie rob wrote:
> Should this decorator be added to the generic views? I can see
> arguments either way. Perhaps it is safer to come up with a different
> generic view (or a parameter) if you never want to cache?
I think it should be added to create/update, becaus
On Friday 31 March 2006 14:20, Luke Plant wrote:
For those who are interested (and for the record):
Here is the relevant bit of the log I was talking about:
GET /admin/officers/application/ HTTP/1.1
Host: [removed]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB; rv:1.8.0.1)
Gecko/2
> I'm not sure if I can really spend any more of my company's time
diagnosing this problem! Certainly the change has worked, and could be
useful for anyone in a similar situation.
No worries. This helps! I'm going to look out for something like this
as well now, and will probably need to patch w
I've actually managed to use Firefox and LiveHeaders to capture an
instance of it doing it. It occurred after deleting an object and then
going back to the list view (which makes sense - I haven't added
@never_cache to the list view yet). I'll analyse the log later.
Luke
--~--~-~--~--
oggie rob wrote:
> I'm a little concerned that you found this - I deployed a similar app
> several months ago and have not heard of a single case of this. (I'm
> using rev 1764.)
Actually, the only place I've discovered it is at my work place, and
from here it does seem to be fixed with the chan
> Opinions? I'll go ahead an implement this if no-one screams.
I'm a little concerned that you found this - I deployed a similar app
several months ago and have not heard of a single case of this. (I'm
using rev 1764.)
Are you sure that changing Django will fix this? If you only found it
when y
On Thursday 30 March 2006 23:34, [EMAIL PROTECTED] wrote:
> yes please.
>
> but since you're adding a flag to the response object, can you add
> perhaps add an official "setter" API to the response class as well ?
>
> (I have applications where a view may want to flag some but not all
> responses
Luke Plant wrote:
> So, I propose adding a 'never_cache' decorator and using it for some of
> the admin views (probably most of the main ones, but shouldn't be
> needed for add_stage). 'never_cache' will add a '_never_cache'
> attribute to the outgoing response object, and then CommonMiddleware
On Thursday 30 March 2006 18:38, Jacob Kaplan-Moss wrote:
> I'd just make the never_cache decorator set the cache-control headers
> on the response object directly instead of the trick with the
> attribute and the piece of middleware.
Yes, that sounds a lot better (don't know why I came up with
On Mar 30, 2006, at 10:56 AM, Luke Plant wrote:
> So, I propose adding a 'never_cache' decorator and using it for
> some of
> the admin views (probably most of the main ones, but shouldn't be
> needed for add_stage). 'never_cache' will add a '_never_cache'
> attribute to the outgoing response o
I have recently gone live with an app mainly using Django's admin,
deployed using mod_python. I've found something I never really
experienced when using the developlement server and developing locally
(for some unknown reason), namely that the browser caches pages
generated by the admin (without
12 matches
Mail list logo
