W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: draft-montenegro-httpbis-uri-encoding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 21 Mar 2014 14:39:14 +0100
Message-ID: <532C4102.4010606@gmx.de>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:25 UTC