Django returns an HTTP 200 on a HEAD request for a non-existing file in the media folder

[sHtev]

I have some Javascript code in a django app that performs a HEAD request on a file to test if it exists. This file is in the media folder of the standard static files setup in development.

However, django returns an HTTP 200 code regardless of whether the file exists or not. Expected behaviour is that it should return a 404 when the file does not exist.

GET requests return a 404 as expected.

[Tim Graham]

I can't reproduce this. How are you serving content in the media folder? I tested using ​static() and saw the following in the development server logs:

[25/Jun/2014 13:56:21] "HEAD /media/foo HTTP/1.1" 404 0

after running:

$ curl -i -X HEAD http://localhost:8000/media/foo

[Steve Gilroy <shtev@…>]

media folder is set up as

STATICFILES_STORAGE = 'require.storage.OptimizedStaticFilesStorage'
CHECKOUT_ROOT = os.path.abspath(os.path.join(PROJECT_ROOT, '..'))
MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(CHECKOUT_ROOT, 'var', 'media')

this could imply an issue with django-require

Django version is 1.5.8

[Steve Gilroy <shtev@…>]

I have tested this with STATICFILES_STORAGE='django.contrib.staticfiles.storage.StaticFilesStorage' and still see the same issue

[Steve Gilroy <shtev@…>]

and I get the 200 with curl as well as Javascript

[Steve Gilroy <shtev@…>]

I realised the problem is that when DEBUG=True is in settings, I am getting a 200, and the content is the standard text reply, rather than a proper 404.

Should this still apply to the media directory though?

[Tim Graham]

What do you mean by "the standard text reply"? What view is returning the response?

[Aymeric Augustin]

I suspect Steve's seeing the yellow debug view.

[Tim Graham]

Attached is what I see on a GET in a browser.

And with curl:

$ curl -i -X HEAD http://localhost:8000/media/foo

HTTP/1.0 404 NOT FOUND
Date: Thu, 26 Jun 2014 20:02:00 GMT
Server: WSGIServer/0.1 Python/2.7.3
X-Frame-Options: SAMEORIGIN
Content-Type: text/html

[Jacob Rief]

I also can replicate this bug. It happens on Django version 1.6 and 1.7. I haven't tested with 1.8 yet.

In order to repeat you have to use any URL in the /media/... path AND the sessionid must be from a logged in staff user.

$ curl --head --cookie sessionid=<valid-session-id-of-staff-user> http://localhost:8000/media/path-to-non-exiting-file
HTTP/1.0 200 OK

$ curl --include --cookie sessionid=<valid-session-id-of-staff-user>  http://localhost:8000/media/path-to-non-exiting-file
HTTP/1.0 404 NOT FOUND

$ curl --head --cookie sessionid=<invalid-session-id> http://localhost:8000/media/path-to-non-exiting-file
HTTP/1.0 404 NOT FOUND

$ curl --head http://localhost:8000/media/path-to-non-exiting-file
HTTP/1.0 404 NOT FOUND

$ curl --head --cookie sessionid=<valid-session-id-of-staff-user> http://localhost:8000/static/path-to-non-exiting-file
HTTP/1.0 404 NOT FOUND

what we see here is, that only the first invocation of curl delivers an unexpected result. All others are correct.

Of course this only happens with DEBUG = True and while delivering media files through Django. Otherwise we'd have to blame Apache or NGiNX.

[Tim Graham]

Could you upload a sample project that can be used to reproduce the error? I tried with the stable/1.7.x branch using curl, but still get a 404 even on the first request.