Static files aren't served correctly on dev server when DEBUG and FORCE_SCRIPT_NAME are enabled

[EugeneM]

/contrib/staticfiles/handlers.py

 def serve(self, request):                                                   
        """Serve the request path."""
--       return serve(request, self.file_path(request.path), insecure=True)
++       return serve(request, self.file_path(request.path_info), insecure=True)

[Natalia Bidart]

Hello Eugene, thanks for your ticket.

Could you please provide some more details on how to reproduce this issue? A description of the necessary setup and/or a small Django test project as a reproducer would be ideal.
Even better a regression test if you would be up for it!

For now I'll mark this report as needsinfo, but I'll reopen as soon as we have more information to properly triage this issue.

Thanks!

[Mariusz Felisiak]

As far as I'm aware this is a duplicate of #30634, #7930, #31724 and few other tickets.

[EugeneM]

Steps to reproduce:

• bootstrap

  mkdir tmp && cd tmp
  virtualenv venv
  . venv/bin/activate
  pip install "Django<5"
  django-admin startproject testme 10.100.100.10:9999
  cd testme && mkdir static && touch static/test.css
  

• nano testme/settings.py && add in the end of file and save

ALLOWED_HOSTS = ['*',]
STATICFILES_DIRS  = [ f'{BASE_DIR}/static' ]

• test if all is ok in browser: ​http://10.100.100.10:9999/static/test.css

• nano testme/settings.py # add in the end of file and save

FORCE_SCRIPT_NAME = '/sub'

• test in browser: ​http://10.100.100.10:9999/static/test.css and get "Page not found (404) 'tic/test.css' could not be found"

• do fix

• test if all is ok in browser: ​http://10.100.100.10:9999/static/test.css

• disable FORCE_SCRIPT_NAME and check ​http://10.100.100.10:9999/static/test.css

Replying to Mariusz Felisiak:

As far as I'm aware this is a duplicate of #30634, #7930, #31724 and few other tickets.

Just because somebody missed it long time ago doesn't mean it's ok.
"Page not found" message with incorrectly truncated file name hints that something went wrong.
Moreover if you can check request.path and 'request.path_path' and see a difference

[EugeneM]

Found out that the ticket was closed but still is interesting in mention about incorrectly truncated path in 404 message.

Why it's ok ?

[Mariusz Felisiak]

Just because somebody missed it long time ago doesn't mean it's ok.

I don't understand your comment, if it's a duplicate you should leave comment in an old ticket and don't open a new one. It doesn't matter how old they are.

Found out that the ticket was closed but still is interesting in mention about incorrectly truncated path in 404 message.
Why it's ok ?

Can you precise what do you mean?

[EugeneM]

Replying to Mariusz Felisiak:

Just because somebody missed it long time ago doesn't mean it's ok.

I don't understand your comment, if it's a duplicate you should leave comment in an old ticket and don't open a new one. It doesn't matter how old they are.

I left a comment in already 'closed' ticket.
I'm not sure that anyone has studied this particular problem and will ever read the closed ticket.
So I 'renew' the ticket for sure as i wasn't able to find an option for 'reopen'.

Found out that the ticket was closed but still is interesting in mention about incorrectly truncated path in 404 message.
Why it's ok ?

Can you precise what do you mean?

I mean if you try the 'test case' that i described above. you'll see a 404 message about existing static file with wrong truncated file path to the file in that 404 message.
I marked this with bold font in 'test case'.

When somebody had closed this ticket , it looks like somebody means 'it's not a bug'='it's ok'.
So I'm still interesting if this 404 message with wrong truncated path is a feature or a bug.
And if this 404 error is a feature, why the message contains wrong truncated file path

[Natalia Bidart]

Hello Eugene,

I have your report and tried your instructions. While I did reproduce the issue as you describe it, the real-world use case is unclear to me. Also, after reading #7930, this report does seem to be a duplicate of such ticket.

If you disagree about this being a duplicate of #7930, could you please explain in detail why this is not a duplicate?

Regarding the fix itself, please read the last comment in #7930 where it's said that nowadays the use of this setting should not be necessary.

If you have a valid use case for this setting, please add a comment to ticket #7930. Thank you!

[EugeneM]

the usecase is very simple = to open webpage when debugging on DEV-server with all dependencies with FORCE_SCRIPT_NAME enabled ( without nginx (or other web server) and collectstatic)

It's also not a duplication of 11 years old ticket #7930, except the subject that "FORCE_SCRIPT_NAME doesn't work correctly with dev-server". That is truth for 11 years =).. BTW It's also a truth that i didn't need and didn't try this "feature" for my 11 years of previous django usage =)
And patch proposed is also clean and very different from that was discussed in #7930

But it's up to you, if you think all is ok.. it's ok =)