I have a CSS code that generates http 304:
[08/Nov/2011 15:22:07] "GET /site_media/logo1.gif HTTP/1.1" 304 0
How can I get a workaround using the Django test server? Any clues?
Best Regards,
The 304 code is not an error. You don't need a workaround. It simply means that the static file has not changed since your browser last accessed it
For more information see the Wikipedia explanation of 3xx status codes.
If you're getting 304 with files you did change, you can force reloading in your browser by checking "Disable cache" in your browser's dev tools (on Chrome/ium, right click on webpage -> inspect element -> go to network tab -> disable cache)
Related
My understanding of setting Cache-Control with a max-age value is that the browser is instructed to Cache the file.
What I then expect is that if I hit "enter" on the address bar for the same link, the browser would return a 200 (from cache) response.
My question is that why is it returning a 304 Not Modified response?
The way I see it is that with the 200 (from cache) the browser no longer makes a connection with the Server to validate the file and immediately just serves the cached content. But with the 304, although the browser will not download the file again and will simply instruct the browser to serve the cached file, it will still need to send a request to validate the freshness of the content.
The assets here are served with Amazon's CloudFront CDN with Amazon S3 buckets as the origin. The Cache-Header there (in S3) have been set already. This was is not an issue for all other self-hosted assets.
Thanks for the help!
EDIT: I found this What is the difference between HTTP status code 200 (cache) vs status code 304?. Additional question: I already have Cache-Control set to max-age=31536000, s-maxage=2592000, no-transform, public and still I'm getting a 304, do it need to set the Expire also? I could cache fine before on self-hosted sites with just the Cache-Control.
You expect to see a 200 with the content, rather than a 304 saying "not modified". That's the browser asking to see if the content is newer than what it has cached. 304 means "no, don't waste your bandwidth, your content is current". It can do this with a couple of methods- etag and if-modified-since.
As an example, we can use your stackoverflow avatar image. When I load that in Chrome and look at the Developer Tools, I can see it has a 304 response and is passing those two headers:
if-modified-since:Thu, 28 Jan 2016 13:16:24 GMT
if-none-match:"484ab25da1294b24f8d9d13afb913afd"
How do I prevent access to my Jetty server from unwanted URLs
10.34.6.67 - - [20/Jan/2015:13:04:05 +0000] "GET /pulse?authon&user=BB493827B64FD8B696FD0B600FA05429&url_heartbeat=1,0,156,156,0&db_conn=1,0,0,0,0 HTTP/1.1" 404 283
In order to determine if a requested URL is valid or not, the connection still needs to occur, and the request still needs to be sent.
The access log line you pasted shows that Jetty returned 404 (not found) for it.
Looks like it did the job with no further effort on your part.
I installed django-cors-headers in my django application.
I want to display svg file in webbrowser.
For first time, its not loading properly and its showing 304 response in network.
Can anyone help me how to rectify this problem?
This response should be fine, it just indicates that your browser has a cached version. It saves Django from having to pass back the response again.
From Wikipedia
304 Not Modified
Indicates that the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match. This means that there is no need to retransmit the resource, since the client still has a previously-downloaded copy.
This sounds like what you are looking for, as the SVG should still be rendered by the browser.
I used wagtail-generator with yoeman to generate a wagtail django project and svg files served by django with django.contrib.staticfiles output application/octet-stream mimetype instead of image/svg+xml mimetype which breaks picture rendering.
I tried this solution without success but I'm sure that using something like nginx to serve static files would fix this (did not try yet).
Based on this answer to another of my questions, I can copy wagtail's template in my templates so I can change the admin logo, but it doesn't fix the svg problem ;)
What I'm getting right now:
And here's the response from Chrome network tab in case it could help:
$ wget http://localhost:8000/static/wagtailadmin/images/wagtail-logo.svg
output:
--2014-07-02 16:14:36-- http://localhost:8000/static/wagtailadmin/images/wagtail-logo.svg
Resolving localhost... 127.0.0.1, ::1, fe80::1
Connecting to localhost|127.0.0.1|:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3082 (3.0K) [application/octet-stream]
Saving to: 'wagtail-logo.svg'
100%[=============================================================>] 3,082 --.-K/s in 0.006s
2014-07-02 16:14:36 (466 KB/s) - 'wagtail-logo.svg' saved [3082/3082]
I've just installed my app on a new server to test something out. Setup all went smoothly, app is running fine with a local mysql database behind it which is fully synced up. The only problem is I can't log in.
I've tried logging in via my frontend, and via the admin. For both, if I enter incorrect details it shows an error message. If I enter correct details it doesn't, but still throws me back to the login page.
There is nothing in the logs to suggest what's going on, all I get in a runserver log is something like:
[26/Jun/2013 15:09:31] "POST /account/login/ HTTP/1.0" 302 0
[26/Jun/2013 15:09:31] "GET /dashboard/ HTTP/1.0" 302 0
[26/Jun/2013 15:09:31] "GET /account/login/?next=/dashboard/ HTTP/1.0" 200 2537
I'm clearly logging in ok, being redirected to the dashboard, then bounced straight back to login.
I'm stumped as to where to start looking to debug this problem. The same setup is running fine elsewhere. Can anyone give me any clues as to where to start looking?
You might check the value of SESSION_COOKIE_SECURE. If set to True, the admin login form will simply redirect to itself. Also check that SESSION_COOKIE_DOMAIN is correct. I don't know how many times I've done this inadvertently in development :)