id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
24139	The response reason phrases should evaluate lazily	Jon Dufresne	nobody	"Motivation for this suggestion comes from a bug I found in my own code. I traced it back to how Django handles HTTP reason phrases.

Suggestion:

If the `status_code` of an HTTP response is set outside of the constructor, the `reason_phrase` will be ""OK"", the default for a 200 response. The calling code is required to take two steps to successfully change the status and reason phrase together.

{{{
response = render_to_response(....)
response.status_code = 503  # Or any status code
# As of now, reason_phrase is still ""OK""
#
# Need the line below -- or something like it -- to successfully update the reason phrase.
response.reason_phrase = REASON_PHRASES[response.status_code]
}}}

I'm suggesting wrap `reason_phrase` as a property. Internal to the response, `reason_phrase` remains `None` unless specified by the calling code. Upon accessing `reason_phrase`, if the value is `None` pull from the default `REASON_PHRASES` based on the current value of `status_code`.

I'd also suggest that any change to the `status_code` automatically sets `reason_phrase` back to `None` to avoid surprise reason phrases.

Right now the `reason_phrase` is set once in the constructor and not updated based on the latest `status_code`.

Pull request to follow.
"	New feature	closed	HTTP handling	dev	Normal	fixed		jon.dufresne@… cmawebsite@…	Accepted	1	0	0	0	0	0