[Python-bugs-list] [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh

noreply@sourceforge.net noreply@sourceforge.net
Fri, 01 Nov 2002 18:55:16 -0800

Bugs item #626543, was opened at 2002-10-21 16:57
You can respond by visiting: 

>Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 doesn't do HTTP-EQUIV & Refresh

Initial Comment:
I just added support for HTML's META HTTP-EQUIV and
zero-time Refresh HTTP headers to my 'ClientCookie'
package (which exports essentially a clone of the
urllib2 interface that knows about cookies, making use
of urllib2 in the implementation).  I didn't make a
patch for urllib2 itself but it would be easy to do so.
I don't plan to do this immediately, but will
eventually (assuming Jeremy thinks it's advisible) -- I
just wanted to register this fact to prevent
duplication of effort.

[BTW, this version of ClientCookie isn't on my web page
yet -- my motherboard just died.]

I'm sure you know this already, but: HTTP-EQUIV is just
a way of putting headers in the HEAD section of an HTML
document; Refresh is a Netscape 1.1 header that
indicates that a browser should redirect after a
specified time.  Refresh headers with zero time act
like redirections.

The net result of the code I just wrote is that if you
urlopen a URL that points to an HTML document like


you're automatically redirected to
"http://acme.com/new_url.htm".  Same thing happens if
the Refresh is in the HTTP headers, because all the
HTTP-EQUIV headers are treated like real HTTP headers.
Refresh with non-zero delay time is ignored (the
urlopen returns the document body unchanged and does
not redirect, but does still add the Refresh header to
the HTTP headers).

A few issues:

0) AFAIK, the Refresh header is not specified in any
RFC, but only here:


(HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe
earlier ones too)

1) Infinite loops should be detected, as for HTTP 30x?
   Presumably yes.

2) Should add HTTP-EQUIV headers to response object, or
   just treat them like headers internally?  Perhaps it
   should be possible to get both behaviours?

3) Bug in my implementation: is greedy with reading
   body data from httplib's file object.



Comment By: Martin v. L÷wis (loewis)
Date: 2002-10-26 09:30

Logged In: YES 

I would try to subclass HTTPHandler, and then provide a
build_opener wrapper that installs this handler instead of
the normal http handler (the latter is optional, since the
user could just do build_opener(HTTPRefreshHandler)).


Comment By: John J Lee (jjlee)
Date: 2002-10-23 19:20

Logged In: YES 

What do you think the solution to the backwards-
compatibility problem is?  Leave urllib2 as-is?  Add a
switch to turn it on?  Something else?

At the moment, I just deal with it in AbstractHTTPHandler.
It would be nice to treat it like the other redirections, by
writing a RefreshHandler -- this would solve the backwards-
compatibility issue.  However, OpenerDirector.error always
calls http_error_xxx ATM (where xxx is the HTTP error code),
so without changing that, I don't think a RefreshHandler is
really possible.  I suppose the sensible solution is just to
make a new HTTPHandler and HTTPSHandler?

Can you think of any way in which supporting HTTP-EQUIV
would mess up backwards compatibility, assuming the body is
unchanged but the headers do have the HTTP-EQUIV headers



Comment By: Martin v. L÷wis (loewis)
Date: 2002-10-23 09:54

Logged In: YES 

In addition to the issues you have mentioned, there is also 
the backwards compatibility issue: Some applications might 
expect to get a meta-refresh document from urllib, then parse 
it and retry themselves. Those applications would break with 
such a change.


You can respond by visiting: