W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: disallowing userinfo in http and https URIs

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 29 Jul 2010 12:34:07 +0200
Cc: Mark Baker <mark@zepheira.com>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <F2E725F5-0098-46C0-94A3-85F50A6045A9@mnot.net>
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
That may be true, but pretty much every client implementation disallows them, and have no plans for changing.

So, I think the only question is whether we completely disallow them, or allow them syntactically in the ABNF but disallow them on the wire in prose. 

Cheers,


On 28/07/2010, at 12:57 PM, Martin J. Dürst wrote:

> 
> 
> On 2010/07/28 13:02, Mark Baker wrote:
> 
>> FWIW, we use this construct in the Akara HTTP server project, but
>> those http URIs are only ever found in configuration files, never on
>> the wire.
>> 
>> The use of userinfo on the wire is obviously a security nightmare, and
>> I welcome bold warnings about its use, but I wonder if requiring they
>> be treated as erroneous is necessary, especially when there's so many
>> existing agents which silently ignore it (just tested Firefox 3.6.8,
>> latest Chrome beta, wget), or support it by initiating basic auth
>> (curl).
> 
> I have only very limited experience with userinfo. However, the one I have doesn't suggest it gets disallowed. There is not much difference between sending passwords in clear in email as:
> 
> go to page http://foo.org/bar
> user: us_only
> password: secret
> 
> and:
> 
> go to page http://us_only:secret@foo.org/bar
> 
> when people are aware of the fact that this page isn't for everybody's eyes. However, the later is way more practical.
> 
> Regards,    Martin.
> 
> -- 
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
> 


--
Mark Nottingham     http://www.mnot.net/
Received on Thursday, 29 July 2010 10:34:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:24 GMT