#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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
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.
