This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients amaury.forgeotdarc, hagen, loewis, tarek
Date 2008-11-17.23:14:00
SpamBayes Score 4.1344467e-07
Marked as misclassified No
Message-id <1226963642.46.0.478314088195.issue4338@psf.upfronthosting.co.za>
In-reply-to
Content
Encoding of basic auth has a loooong story. I keep forgetting the
details, but one interpretation is that the it needs to be MIME B or Q
encoded first (i.e. through a header encoding), which then needs to be
base64 encoded. For B or Q, you can chose any IANA-registered encoding.

This is not directly specified, but rather an implicit interpretation of
RFC2617, through reference to RFC2616 by using the TEXT production,
which is defined (in 2.2 of 2616) to be either Q or B encoded, unless it
is iso-8859-1 (which apparently can pass unencoded).

Another interpretation is that it should be UTF-8, based on the general
policy of RFC 2277 mandates UTF-8 for all new protocols.

Yet another interpretation is that RFC2617 just doesn't support
non-ASCII user names and passwords.

It is the latter interpretation that we should implement (perhaps with a
comment that this interpretation is debated). However, it does have the
advantage of being a subset of the two other interpretations (which
otherwise contradict each other). For PyPI, I believe it is safe to
assume that both usernames and passwords are restricted to ASCII.
History
Date User Action Args
2008-11-17 23:14:02loewissetrecipients: + loewis, amaury.forgeotdarc, tarek, hagen
2008-11-17 23:14:02loewissetmessageid: <1226963642.46.0.478314088195.issue4338@psf.upfronthosting.co.za>
2008-11-17 23:14:01loewislinkissue4338 messages
2008-11-17 23:14:00loewiscreate