Improper error on bad user about pydelicious

[GoogleCodeExporter]

most definitely, yes
i will look into this

Original comment by [email protected] on 12 Feb 2010 at 6:54

• Changed state: Accepted

[GoogleCodeExporter]

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 [email protected] on 12 Feb 2010 at 7:08

• Changed state: Invalid

[GoogleCodeExporter]

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 [email protected] on 13 Feb 2010 at 7:38

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 [email protected] on 13 Feb 2010 at 9:36

[GoogleCodeExporter]

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 [email protected] on 14 Feb 2010 at 8:38

[GoogleCodeExporter]

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 [email protected] on 15 Feb 2010 at 8:59

[GoogleCodeExporter]

Original comment by [email protected] on 21 Nov 2010 at 1:54

• Changed state: WontFix