- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 21 Mar 2014 14:39:14 +0100
- To: Nicolas Mailhot <nicolas.mailhot@laposte.net>, Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Gabriel Montenegro <gabriel.montenegro@microsoft.com>
On 2014-03-21 14:24, Nicolas Mailhot wrote: > > Le Ven 21 mars 2014 13:54, Bjoern Hoehrmann a écrit : >> * Nicolas Mailhot wrote: >>> Really, can't you read the abundant documentation that was written on the >>> massive FAIL duck typing is for encoding (for example, python-side)? Code >>> passing unit tests then failing right and left as soon as some new >>> encoding combo or text triggering encoding differences injected in the >>> system? Piles of piles of partial workarounds till there was complete >>> loss >>> of understanding how they were all supposed to work in the first place? >>> >>> That's the last thing you want to reinvent on security equipments (and >>> you'll reinvent it because the amount of non-ASCII urls is small now but >>> will only grow with time). >> >> Julian asked for a concrete example use case. So far you have not given >> one. It might help to assume the rest of us understands the subject at >> hand at least as well as you do. > > As I wrote last time he asked the same question, on some of our networks > accesses are controlled by regex-like checks on URL and not knowing the > encoding of processes URLs means this processing (and the processing of > security logs) is unreliable. > ... I understand the pain caused by having to apply heuristics. What I don't understand is how an out-of-band signal that can be incorrect helps. If this is about security-related checks, you can't trust it anyway, no? Best regards, Julian
Received on Friday, 21 March 2014 13:45:35 UTC