[Django] #24137: Reason phrases use all upper case by default; standard suggests title case
Django
--------------------------------------+--------------------
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+--------------------
Reason phrases were added in ticket #12747. The phrases were added as all
upper case.
When looking at the HTTP standard as reported by different sources. The
default phrases are never all upper case. Instead they typically use a
title case where the first letter of each word is capitalized and the
remaining words are lower case. I found it odd and unusual that Django
would follow a different default here.
Pull request to follow.
See documentation at:
* https://www.ietf.org/rfc/rfc2616.txt
* http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
* http://www.iana.org/assignments/http-status-codes (referenced in Django
code)
--
Ticket URL: <https://code.djangoproject.com/ticket/24137>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
Upper case for this phrases were introduced long ago, see
6e034a831aea204b39f4863eddfbc223a638fb76 (from 2005). The only concern is
backwards compatibility, of course. Maybe a string subclass which could
compare case-insensitively?
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:1>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jdufresne):
* cc: jon.dufresne@… (added)
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/3902
> Maybe a string subclass which could compare case-insensitively?
I can certainly look into adding this.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:2>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
What problems does uppercase cause in practice?
I'm not in favor of adding the complexity of a str subclass if we don't
have a compelling reason.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:3>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
The patch looks good. Reusing the stdlib's list makes sense. I prefer
documenting the change than adding complexity.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:4>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
Aymeric, my only concern is that all tests comparing reason phrases will
suddenly fail after upgrading. But if you think this is an acceptable
backwards incompatibility if documented, then fine for me.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:5>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* needs_better_patch: 0 => 1
Comment:
I've made some comments on the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:6>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by aaugustin):
Browsers ignore the phrase and only look at the code. Our
[https://docs.djangoproject.com/en/1.7/topics/testing/tools/#django.test.SimpleTestCase.assertContains
testing tools] encourage testing the status code.
That's why I don't think many people test the phrases and I'm not too
worried about making a backwards-incompatible change in this area.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:7>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
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
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Comment (by aaugustin):
While there are still some details to figure out, I think the PR is on the
right track.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:9>
Django
Reporter: jdufresne | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by jdufresne):
* needs_better_patch: 1 => 0
Comment:
I have updated the PR by incorporating feedback from reviews.
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:10>
Django
Reporter: jdufresne | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by collinanderson):
* cc: cmawebsite@… (added)
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:11>
Django
Reporter: jdufresne | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: HTTP handling | Version: master
Keywords: | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"24b2bc635e23e4235f51095fbe099beec27a65c8"]:
{{{
#!CommitTicketReference repository=""
revision="24b2bc635e23e4235f51095fbe099beec27a65c8"
Fixed #24137 -- Switched to HTTP reason phrases from Python stdlib.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/24137#comment:12>