wpf5511 / pydelicious

Automatically exported from code.google.com/p/pydelicious
Other
0 stars 0 forks source link

Improper error on bad user #32

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
It took me ages to figure out what was going on, but apparently when a bad 
username/password combination is given to pydelicious it will return a 
PyDeliciousThrottled exception, which is quite a bit misleading.

Original issue reported on code.google.com by swi...@gmail.com on 10 Feb 2010 at 10:49

GoogleCodeExporter commented 8 years ago
most definitely, yes
i will look into this

Original comment by berend.v...@gmail.com on 12 Feb 2010 at 6:54

GoogleCodeExporter commented 8 years ago
sorry i need some more info, cannot reproduce this.

Ìnvalid password and username produce a "PyDeliciousUnauthorized: Check 
credentials.", triggered by the not unexpected 401 in this case. 
The 0.5.0 dist raises "PyDeliciousException: HTTP Error 401: Unauthorized"

There is no reason you should be throttled while you haven't even downloaded 
data so 
I have little clue as to what else may be wrong. 503 does mean ofcourse Service 
Unavailable, i don't know what other situations delicious.com may serve it.

Original comment by berend.v...@gmail.com on 12 Feb 2010 at 7:08

GoogleCodeExporter commented 8 years ago
Here's the traceback leading up to the error:
http://pastebin.com/f23dce8d2

And here's the relevant code that tries to post to Delicious:
http://pastebin.com/f29387894

Hope that helps figuring out what's wrong. From the traceback I can clearly see 
that a 
bad authorisation attempt happens first and after it's retried a Throttled 
error comes 
back.

Far as I can tell we're using the latest version of pydelicious; from the 
read-only svn 
checkout.

Original comment by swi...@gmail.com on 13 Feb 2010 at 7:38

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Agreed, but that code is in urllib2. So at the HTTP level, unless some funny 
headers 
get send I don't understand the 503.

Does pydelicious work normally otherwise? It still appears you get a 503 from 
http:api.del.icio.us, not from pydelicious. Does it log in with correct 
credentials?

From the trace; urllib2 is retrying the HTTP basic auth upon 401, delicious 
then 
decides to serve 503, pydelicious assumes this is a throttled response.

This seems to be the same behaviour as in my 2.5.1 setup,
here is an invalid password stacktrace: http://pastebin.com/m28263da6

It looks like del.icio.us is serving a 503 nonetheless. Perhaps you can debug 
HTTP 
response headers to confirm.

btw, this is in SVN but used 0.5.0 to check previous behaviour.

Original comment by berend.v...@gmail.com on 13 Feb 2010 at 9:36

GoogleCodeExporter commented 8 years ago
Is it possible that when urllib2 retries authentication Delicious then 
throttles this 
request because it happens within the same second?

Which leads me to wondering, is it possible to tell urllib not to retry 
authentication?

Original comment by swi...@gmail.com on 14 Feb 2010 at 8:38

GoogleCodeExporter commented 8 years ago
1. I dont' know, perhaps, you'd have to confirm that yourself by running a 
test. 
Perhaps writing the same HTTP GET with Basic auth to a socket twice. If so, 
please 
post any (relevant) headers.
2. I would hope so but have not found out how. You might figure out which 
opener-
handler is causing this, subclass this Handler and override some method, and 
then pass 
that to the build_opener.

Original comment by berend.v...@gmail.com on 15 Feb 2010 at 8:59

GoogleCodeExporter commented 8 years ago

Original comment by berend.v...@gmail.com on 21 Nov 2010 at 1:54