Code

Opened 4 years ago

Closed 4 years ago

#13571 closed (wontfix)

Static files server for dev doesn't behave as expected with flatpage app

Reported by: christandiono Owned by: nobody
Component: Uncategorized Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Or does it? (I tried searching for this bug but I didn't find it...)

The problem happens when a flatpage has the same URL as a static files directory.

The way the static server works is it adds an extra URL pattern: for everything that's not covered by the other URLs in urls.py, first try to serve it as a static file, then if the file doesn't exist return 404. The flatpage middleware waits for a 404, and if there is a 404 it will show the flatpage.

So in production, the flatpage will be served first before attempting to show the directory contents (if allowed by .htaccess or httpd.conf or whatever it is that's being used). For the dev server, the directory contents will be served first before attempting to show the flatpage.

The workaround is to disable showing directory listings in the configuration for the static files server.

I don't really know if this is worth fixing, but it's kind odd to have to disable showing directory listings (which may be useful) in order to show flatpages. At the very least it's unintuitive...

Attachments (0)

Change History (1)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

This isn't really a problem with the flatpages app; it's an inconsistency in the way static media being served. It will also be entirely dependent on your deployment configuration. If your deployment rules match your static media directory before your Django app, then static media will take priority; if the Django app is matched first, it will take priority.

Marking wontfix because this is something where we literally can't fix the problem; it just falls into that annoying category of bugs that will emerge during deployment.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.