#34989: APPEND_SLASH redirects much slower in Django 4.2 when used with uWSGI's
http11-socket
-------------------------------------+-------------------------------------
Reporter: Jeppe Fihl-Pearson | Owner: Anders
| Kaseorg
Type: Bug | Status: new
Component: HTTP handling | Version: 4.2
Severity: Normal | Resolution:
Keywords: CommonMiddleware | Triage Stage:
uWSGI | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Florian Apolloner):
* status: closed => new
* resolution: invalid =>
Comment:
Yeah, in general I'd expect the server to optimize where possible, so it
is rather surprising that uWSGI doesn't do that.
It is unfortunate that `HttpResponse` does not have a `__len__` and we
cannot monkey patch it onto it while also supporting streaming via
generators without a known length because Python does something along the
lines of `type(x).__len__(obj)`, so even if `hasattr()` sees `__len__`,
calling `len()` on it works only if the class has `__len__`.
I also guess we might not exactly be able to get rid of setting the
`Content-Length` in the `CommonMiddleware` because we document it:
https://docs.djangoproject.com/en/4.2/ref/middleware/#module-
django.middleware.common
So the way I see it we have two options:
* Improve the `CommonMiddleware` as in your PR (I am saying improve and
not fix, because technically Django does nothing spec incompatible, so it
is rather a performance improvement. No matter how we spin it, there is a
deeper bug in uWSGI I think -- this also means there will be no
backports).
* Also add a similar code to our WSGI/ASGI handlers and set the `Content-
Length` where possible. I am in favor of doing this, since Anders is right
that a server cannot optimize given that `HttpResponse` has no `__len__`.
I am slighty worried about backwards compatibility here though, but I
honestly cannot think of a case where setting the `Content-Length` would
cause problems.
As such I am preliminarily reopening the ticket and if Mariusz is fine
with it let's set it to accepted. The title etc will be a little bit off
then, but I guess that is fine.
Would you mind opening a ticket against uWSGI and cross-link it here?
--
Ticket URL: <https://code.djangoproject.com/ticket/34989#comment:11>
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018bf89dc315-303a2131-c980-400b-96c4-1b28ffde43af-000000%40eu-central-1.amazonses.com.
