Changes between Initial Version and Version 1 of Ticket #34028, comment 6


Ignore:
Timestamp:
Sep 24, 2022, 2:14:22 PM (20 months ago)
Author:
Stewart Adam

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #34028, comment 6

    initial v1  
    4646> That said it is true that the value of `SCRIPT_NAME` is assumed to be static and not change over the runtime of Django. If Django is "loaded" outside of a webcontext first, then you will see the behavior you are describing. I'll accept the ticket for now but I am not sure if this is fixable easily or at all.
    4747
    48 I agree at face value this might be an unusual thing to support, however on many servers healthchecks or other internal requests might result in a request coming through without SCIRPT_NAME set as it would be for end-users via reverse proxy.
     48I agree at face value this might be an unusual thing to support, however I can see a few cases where this might happen:
     49
     501. middleware initializes and accesses settings before a request arrives (e.g. whitenoise appears to do this) - SCRIPT_NAME won't be set from the HTTP request at that point in time
     512. on many servers healthchecks or other internal requests might result in a request coming through without SCIRPT_NAME set as it would be for end-users via reverse proxy.
     52
     53It seems like for configuring the Django prefix when hosted in a sub-paths, it should either (a) move to a hardcoded config-based value so the prefix is the same in all contexts or (b) reset the thread locals based on the request headers - but right now behavior appears to be a mix of both which is what causes issues.
Back to Top