> "The action required MAY be carried out by the user agent without interaction with the user if and
> only if the method used in the second request is GET or HEAD".
> 
> By this, I understand, RFC means, for the POST data, the user is made aware and is conscious of the
> redirect which is happening and is "permitting" to POST the data to new location.

My reading too.

> The interaction happens like this:
> User: Post to /a
> Browser: Posts to /a and Server says oh /a is /b
> Browser: Hello user! Server says /a is now /b. Shall I post to /b?
> User: Yes, you may.
> 
> This is different from what you are saying, which is like with having an option in the browser settings
> which will enable following redirect on POST.

The big difference that I see is that urllib is a library, not a browser.  A browser could be implemented on top of urllib, and it is the browser’s responsibility to ask the user if they want POST data to be sent again.  The browser then needs to tell urllib to forward POST data: this is the piece that’s missing.

> In a similar way, developers using urllib as library in their applications can obtain the redirected URL
> and then POST to the redirected URL. That would be equivalent behavior.

Ah, so there is a way to achieve it!  If Jay is satisfied by this, we could add an example of using that in the urllib howto, with the appropriate warnings.  That would have much less risk than a new parameter.