- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Fri, 21 Mar 2014 11:55:33 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Mark Nottingham" <mnot@mnot.net>, "HTTP Working Group" <ietf-http-wg@w3.org>, "Gabriel Montenegro" <gabriel.montenegro@microsoft.com>
Le Ven 21 mars 2014 09:13, Julian Reschke a écrit : > On 2014-03-21 08:59, Nicolas Mailhot wrote: >> ... >>> My concerns are the same as when this was presented first: how does >>> this >>> help? >>> >>> I hear that it makes security checks more reliable, but then, you can't >>> rely on the header field being accurate >> >> There is a difference between working in heuristics mode all the time >> with >> crossed fingers and rabbit legs and working in deterministic mode with >> simple error handling (and error handling can be abort when what the >> other >> node declares and what you receive are different – much more secure than >> generalized guesswork) > > So how *exactly* does the header field help you in deciding whether to > be in heuristics mode or not? If I know the encoding is supposed to be UTF-8 I can fail anything that does not pass the usual UTF-8 sanity rules instead of iterating through encodings hoping I find the right one before hitting a security bug If I know my app is open to European users only I can block user agents that try to use a CJK encoding before they manage to hit a CJK processing bug I don't have to log random ascii-ified percentage garbage in the hope that the day it will need to be analysed and interpreted I'll have enough human beings to review it line by line and assign the encoding necessary to interpret it line by line. -- Nicolas Mailhot
Received on Friday, 21 March 2014 10:56:27 UTC