Author mcepl
Recipients mcepl
Date 2013-11-04.15:00:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za>
In-reply-to
Content
GitHub API v3 is intentionally broken (see http://developer.github.com/v3/auth/):

> The main difference is that the RFC requires unauthenticated requests to be answered with 401 Unauthorized responses. In many places, this would disclose the existence of user data. Instead, the GitHub API responds with 404 Not Found. This may cause problems for HTTP libraries that assume a 401 Unauthorized response. The solution is to manually craft the Authorization header.

Unfortunately, urllib2.HTTPBasicAuthHandler relies on the standard-conformant behavior. So a naive programmer (like me) who wants to program against GitHub API using urllib2 (and foolishly ignores this comment about the API non-conformance, because he thinks GitHub wouldn't be that stupid and break all Python applications) uses for authentication something like the example script on http://docs.python.org/2/howto/urllib2.html#id6, spends couple of hours hitting this issue, until he tries python-requests (which work) and his (mistaken) conclusion is that urllib2 is a piece of crap which should never be used again.

I am not sure how widespread is this breaking of RFC, but it seems to me that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which just en passant expects urllib2 authentication stuff to be useless), and the question is whether it shouldn't be documented somehow and/or urllib2.HTTPBasicAuthHandler shouldn't be modified to try add Authenticate header first.
History
Date User Action Args
2013-11-04 15:00:19mceplsetrecipients: + mcepl
2013-11-04 15:00:19mceplsetmessageid: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za>
2013-11-04 15:00:19mcepllinkissue19494 messages
2013-11-04 15:00:18mceplcreate