#26293: Warnings regarding 404s logged for URLs missing trailing slashes
-------------------------------------+-------------------------------------
Reporter: jklaiho | Owner: the-kid89
Type: Bug | Status: assigned
Component: HTTP handling | Version: 1.9
Severity: Normal | Resolution:
Keywords: CommonMiddleware | Triage Stage:
404 logging regression | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by the-kid89):
* owner: nobody => the-kid89
* status: new => assigned
Old description:
> I recently deployed a project into production using Django 1.9.2 and
> started getting strange logged warning messages from Sentry for 404's.
> Looking into it, this occurred in
> `django.core.handers.base.BaseHandler.get_response` and was related to
> people visiting URLs without trailing slashes.
>
> I compared the behaviour against an earlier, similarly configured project
> still running Django 1.7.x and this didn't occur there.
>
> Digging deeper, it seems that commit
> [https://github.com/django/django/commit/434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8
> #diff-1f8be0eae49a1bf37d52829eaeda6a4e 434d309e] to fix [ticket:24720]
> inside `CommonMiddleware` was causing this. In lines 56-66 (58-68 in
> 1.9.2), the path is only checked for a missing slash if the prerequisites
> for `PREPEND_WWW` processing are met, since they are indented beneath it.
> This doesn't really make sense, since the two settings are not
> interdependent.
>
> As a result, an `Http404` is raised after request middleware processing
> in `BaseHandler.get_response`, at which point a warning is logged—for
> every single request for a path without a trailing slash.
>
> `APPEND_SLASH` still takes effect eventually, but only when
> `CommonMiddleware` is called again, this time for `process_response`,
> whereupon the normal redirect gets done. Thanks to this, everything
> appears to function normally for the end user, but unnecessary 404
> warnings end up getting logged. (Though if `APPEND_SLASH` was `False`,
> you'd probably want them logged.)
>
> It seems to me that `CommonMiddleware.process_request` needs a bit of
> reworking to run the checks for `PREPEND_WWW` and `APPEND_SLASH`
> independently, and to determine the need for a redirect based on whether
> at least one of these is necessary, still fulfilling the purpose of
> [ticket:24720]. I've provisionally marked the ticket as "easy pickings",
> as it seems to be that way from my admittedly limited research into this.
New description:
I took a look over it and you are correct that APPEND_SLASH wil not run
unless PREPEND_WWW is also set. =
I recently deployed a project into production using Django 1.9.2 and
started getting strange logged warning messages from Sentry for 404's.
Looking into it, this occurred in
`django.core.handers.base.BaseHandler.get_response` and was related to
people visiting URLs without trailing slashes.
I compared the behaviour against an earlier, similarly configured project
still running Django 1.7.x and this didn't occur there.
Digging deeper, it seems that commit
[https://github.com/django/django/commit/434d309ef6dbecbfd2b322d3a1da78aa5cb05fa8
#diff-1f8be0eae49a1bf37d52829eaeda6a4e 434d309e] to fix [ticket:24720]
inside `CommonMiddleware` was causing this. In lines 56-66 (58-68 in
1.9.2), the path is only checked for a missing slash if the prerequisites
for `PREPEND_WWW` processing are met, since they are indented beneath it.
This doesn't really make sense, since the two settings are not
interdependent.
As a result, an `Http404` is raised after request middleware processing in
`BaseHandler.get_response`, at which point a warning is logged—for every
single request for a path without a trailing slash.
`APPEND_SLASH` still takes effect eventually, but only when
`CommonMiddleware` is called again, this time for `process_response`,
whereupon the normal redirect gets done. Thanks to this, everything
appears to function normally for the end user, but unnecessary 404
warnings end up getting logged. (Though if `APPEND_SLASH` was `False`,
you'd probably want them logged.)
It seems to me that `CommonMiddleware.process_request` needs a bit of
reworking to run the checks for `PREPEND_WWW` and `APPEND_SLASH`
independently, and to determine the need for a redirect based on whether
at least one of these is necessary, still fulfilling the purpose of
[ticket:24720]. I've provisionally marked the ticket as "easy pickings",
as it seems to be that way from my admittedly limited research into this.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/26293#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.514118a6750804c7c039317861dc2904%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
