Django -- messing with the test server -- 304 errors and such

While working on my webapp (which requires a login for the entire site) I noticed a funny "glitch" (if you can call it that). I was viewing my Django site, logged into the site (on the test server) in Chrome. I then logged out of my site and closed Chrome entirely.

I then opened Firefox and pasted in the URL to my Django site, expecting to be taken to the login page. However, I was not asked to log in, b开发者_如何学运维ut rather was already logged in. So I proceeded to log out of the site and close Firefox.

I then re-opened Chrome to log in, only to find that there was no CSS styling. I logged in and the whole site had lost its CSS styling and the test server kept given the 304 errors for all CSS and IMG files.

I've figured out that the 304 error has something to do with time mis-matching (like Django thinking I was logged out, but in Firefox I was logged in -- so now it is confused).

I was just wondering if this is avoidable, or if it is a "feature" of the test server? Will this kind of thing happen in production mode too?

EDIT for clarity of what I'm asking:

Will the loss of styling and images due to the 304 error that I am experiencing with the Django test server continue to occur when I launch the webapp with Apache?

Thanks!

You've got questions about three things:

1. Why you were logged in in Firefox.
2. Why you lost your CSS styling in Chrome.
3. What all those 304 responses are.

Unfortunately there are quite a few possible explanations for the first two issues you're seeing. Most likely there's nothing too serious going wrong.

For the first two issues you could try reverting to a fresh state and then seeing if the problems still occur. e.g. Use a clean Django database (with no sessions) and try to clear all your cached browser information (cookies, auth, cached files). Admittedly this is quite a time consuming way to test for problems, but its the best general advice I can give without being able to examine your situation directly.

Luckily 304 responses aren't a problem at all. A 304 just means that the browser has the file in its cache. See Conditional View Processing:

When the client next requests the same resource, it might send along a header such as If-modified-since, containing the date of the last modification time it was sent, or If-none-match, containing the ETag it was sent. If the current version of the page matches the ETag sent by the client, or if the resource has not been modified, a 304 status code can be sent back, instead of a full response, telling the client that nothing has changed.