#24137: Reason phrases use all upper case by default; standard suggests title
case
--------------------------------------+------------------------------------
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by jdufresne):
Replying to [comment:3 aaugustin]:
> What problems does uppercase cause in practice?
I can share my motivation.
I was analyzing request/responses in Firefox and noticed that Django's
requests always looked different than Apache static file requests and PHP
requests. The main difference, of course, was that Django returned all
upper case for reason phrases. I investigated if one was more correct than
the other. The HTTP standard ''recommends'' using title case, but it is
true that it is merely a recommendation. As stated in the standard, the
reason phrase is for humans only. My thinking:
* Title case is easier to read for most English reading humans (probably
why it is recommend)
* Django has no good reason to use a non-recommended reason phrase (there
is no benefit)
* Use Python stdlib code to reduce duplication and maintenance
* Why go out of the way to make Django responses appear different?
Having thought about this some more, I think there is a ''very slight''
(I'd like to emphasize very slight) security implication here. If Django
always looks different, a malicious user could use this difference to know
when a request is served by Django instead of some other application
server. If there is a known exploit -- perhaps recently made public by a
release -- this information could allow the malicious user to find Django
servers and use that known exploit.
Now, I'm not saying there aren't other Django identifying factors, I'm
sure there are. But this is one step in that direction.
> I'm not in favor of adding the complexity of a str subclass if we don't
have a compelling reason.
Personally, I agree. I don't see the benefit of adding a `str` subclass.
Generally, machines should be using the status code and not the reason
phrase (which can be altered). The status code has very specific meaning
while the reason phrase is intended for humans only.
At this point I have not investigated adding a `str` subclass in the PR.
Unless there is a strong suggestion to do it in order to finish the PR, I
will not.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:8>
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/067.49da0c0006a6f34966cdf5acbbf047b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
