Should requests honor http-equiv meta refresh?

[mattklein]

It's possible for a server to instruct a client to redirect to a URL by using the http-equiv meta tag. It's antiquated, but it's still out there, and browsers still handle it as a redirect.

Should requests honor the http-equiv refresh, handling it essentially the same as a 301? I'd like to think so, because that's what browsers do. To do so would mean having requests parse the section of the response body -- which shouldn't be too difficult or inefficient (even without BeautifulSoup ;). Has this been considered/addressed?

[umbrae]

IMO this seems very much overkill for an HTTP library—not all HTTP is HTML, and even when it is, this would be something that could be pretty easily built by a user who needed it.

[kennethreitz]

Like @umbrae said, this is an HTTP library, not an HTML library.

[mattklein]

Fair points, I definitely respect the desire to keep the library small and focused, and love requests for what it is. For me the question came down to how much you want requests to be able to quack like a browser. I guess the more fitting solution for that need is mechanize.

Here's a thread from way back when John Lee added support for http-equiv into "ClientCookie" (which later became mechanize), including a debate about whether/how that support should be integrated into urllib2. It wasn't, but mechanize's HTTPEquivProcessor is available for use with urllib2 to do what I want -- hande http-equiv tags as if they were HTTP headers.