[Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implementations

[nobody]

Bugs #407783, was updated on 2001-03-11 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
Status: Open
Priority: 5
Submitted By: Bill Bumgarner
Assigned to: Jeremy Hylton
Summary: urllib2: AbstractHTTPHandler limits flexible client implementations

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


----------------------------------------------------------------------

Comment By: Bill Bumgarner
Date: 2001-03-11 19:59

Message:
Logged In: YES 
user_id=103811

I realized that the exception throw behaviour is more fundamental to the underlying implementation than may have been indicated in the above description.  In particular, throwing an HTTP exception when handling a 401 is key to making the various Authentication Handlers work.

I still feel that the behaviour should be normalized across all requests such that the callee is responsible for determining error conditions or, at the lest, has access to the same data in a relatively similar format upon success or failure.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470