Closed GoogleCodeExporter closed 9 years ago
most definitely, yes
i will look into this
Original comment by berend.v...@gmail.com
on 12 Feb 2010 at 6:54
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
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
[deleted comment]
[deleted comment]
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
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
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
Original comment by berend.v...@gmail.com
on 21 Nov 2010 at 1:54
Original issue reported on code.google.com by
swi...@gmail.com
on 10 Feb 2010 at 10:49