How do you stop urllib.request.urlopen from following a redirect?

## urlopen is a facade over a handler chain `urllib.request.urlopen` is not the client; it is a convenience wrapper around a default `OpenerDirector` assembled once and cached. That opener holds an ordered chain of handlers — one that knows how to open `http` URLs, one that knows `https`, one that raises for error statuses, one that manages redirects. Anything you want to change about client policy, you change by building your own opener with `urllib.request.build_opener`, which starts from the default chain and lets your handler classes replace the built-in ones of the same type. That is the mental model the question is really testing. There is no `allow_redirects=False` keyword anywhere in `urllib.request`, and there never has been. Policy lives in handlers. ## What the redirect handler does by default `urllib.request.HTTPRedirectHandler` intercepts 301, 302, 303, 307 and 308 responses. For each, it builds a new `Request` for the `Location` target and re-enters the opener, transparently, so the caller sees only the final response. Its class attributes cap the process: `max_redirections` stops a chain at ten hops, and `max_repeats` stops it after four visits to the same URL. Exceed either and it raises `HTTPError` complaining about a redirect loop. Two rewrite rules matter in practice: * **A POST redirected by 301, 302 or 303 becomes a GET.** The handler builds the follow-up request with the method rewritten and the body dropped, and it strips the `Content-Type` and `Content-Length` headers on the way. Your carefully constructed POST arrives at the destination as a bodyless GET. * **A POST is never replayed on 307 or 308.** Rather than re-sending the body, urllib raises `HTTPError` with that status. This surprises people who expect the client to honour the 'repeat the request as-is' intent; the standard library simply declines and hands the decision back to you. Headers you attached with `add_header` — including everything in the `headers` dict you passed to `Request` — *are* copied onto the follow-up request, even when the redirect points at a different host. Only the two content headers are dropped. Headers attached with `add_unredirected_header` are not copied; that method exists precisely so a header is not replayed, and urllib uses it for the headers it fills in itself. If a header must not travel to an unexpected destination, refusing the redirect and re-issuing the request deliberately is the mechanism the library gives you. ## Refusing to follow `redirect_request` is the extension point. It is documented as returning a `Request` to follow, raising `HTTPError` to stop everything, or returning `None` to mean 'I decline, let another handler try'. Since no other handler in the chain wants a 3xx, returning `None` means the response falls through to `HTTPDefaultErrorHandler`, which raises `HTTPError`. The exception then carries the status and the response headers, so `Location` is readable in the handler. ```python import urllib.request class NoRedirect(urllib.request.HTTPRedirectHandler): def redirect_request(self, req, fp, code, msg, headers, newurl): return None opener = urllib.request.build_opener(NoRedirect) ``` The same seam supports the other things people want: logging every hop, capping the chain lower than ten, refusing a redirect that leaves the original host, or refusing one that would drop your body. Override `redirect_request`, decide, and either return a `Request` or refuse. Use `open` on your opener rather than `urlopen`, which keeps the policy local to the call site. `urllib.request.install_opener` makes your opener the process-wide default that `urlopen` uses — convenient in a small script, and a hidden global in anything larger, because a later reader has no way to tell from the `urlopen` call that redirect policy has changed. ## Knowing where you landed When a redirect *is* followed, the object `urlopen` returns has its `url` attribute set to the URL of the last request urllib actually made, so it is the final destination rather than the URL you asked for. Its `status` is the final response's status: a followed chain looks like a plain 200, and nothing on the returned object records the hops. If the chain matters — for an audit trail, or because a redirect is itself the signal — you must refuse the redirect and walk it yourself. ## What an interviewer is listening for The shape of the answer is: urlopen is a facade, redirects are handled by a handler in the opener's chain, you change behaviour by subclassing the handler and building your own opener, and refusing means returning `None` and catching the resulting `HTTPError`. The bonus marks come from knowing that a POST silently becomes a GET on 301, 302 and 303, that 307 and 308 raise instead, and that the final URL is on the response object rather than anywhere in your own code.