Reason phrases use all upper case by default; standard suggests title case

[Jon Dufresne]

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)

[Claude Paroz]

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?

[Jon Dufresne]

​https://github.com/django/django/pull/3902

Maybe a string subclass which could compare case-insensitively?

I can certainly look into adding this.

[Aymeric Augustin]

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.

[Aymeric Augustin]

The patch looks good. Reusing the stdlib's list makes sense. I prefer documenting the change than adding complexity.

[Claude Paroz]

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.

[Claude Paroz]

I've made some comments on the PR.

[Aymeric Augustin]

Browsers ignore the phrase and only look at the code. Our ​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.

[Jon Dufresne]

Replying to 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.

[Aymeric Augustin]

While there are still some details to figure out, I think the PR is on the right track.

[Jon Dufresne]

I have updated the PR by incorporating feedback from reviews.

[Tim Graham <timograham@…>]

In 24b2bc635e23e4235f51095fbe099beec27a65c8:

Fixed #24137 -- Switched to HTTP reason phrases from Python stdlib.