> On 10 Mar 2016, at 18:36, Andrew Godwin <and...@aeracode.org> wrote:
> Second, if it were me I’d remove the `status_text` field on the `Response` 
> object. Custom status text is a terrible misfeature (especially as HTTP/2 
> doesn’t support it), and in 99% of cases you’re just wasting data by 
> repeatedly sending the default phrase that the server already knows.
> Well, it IS optional; you only need to send it if you're changing it from the 
> default or providing an unusual new value (e.g. 418). We could change the 
> spec to say servers don't have to abide by it, too. I have done a project in 
> the past with custom reason phrases, that's all :)

You monster! ;)

For what it’s worth, I object to the use of reason phrases because, as with all 
things in HTTP, they were far-too-broadly specified. The rules for parsing the 
reason phrase are super broad (the reason phrase allows \t, space, and then all 
bytes from 0x21 to 0xFF *excluding* 0x7F (ASCII DEL). This means that it’s 
sometimes possible to encode a reason phrase containing non-ASCII/non-Latin-1 
codepoints in UTF-8 (I’ve seen this happen), and then everything gets really 
terrible really fast.

IMO, I think almost nothing would be lost by just quietly removing it from the 
specification. The only loss is in setting “unusual” values, and FWIW I think 
that’s *also* unwise: if it can’t be found here[0] then the unusual status code 
is nothing but vanity, because it’s no more precise than the X00 version that 
already exists (no user agent can take action on it).

Again, just my 2¢.


[0]: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to