This is certainly possible with Internet Explorer under Windows, but I'm not sure about all the other browsers and platforms. With IE the POST data must be "packed".
Logged In: YES user_id=6380 Why would you need this? I find it hard to imagine a situation where I'd need this. Almost any forms that I would want to reach through webbrowser support GET anyway.
Logged In: YES user_id=228025 If POST is not supported, there is a limit to the size of data that you can send; the limit will be different depending on each browser, but will always be less than 4K URL length limit. Many sites don't accept GET instead of POST for form data. Unfortunately, it is often difficult to tell whether a site accepts GET without changing the form manually and attempting a GET. Sometimes the reason that GET isn't accepted is do to lazy programming, but since a user can't do anything about that they still end up needing POST. Other times it is specifically because a site doesn't want the POST data to be cached. Any GET request will end up getting cached in proxies, show up in server logs, and also cached on the local client. All of these are bad from a security standpoint. POST data is never cached. This is not a critical addition to the webbrowser module, it simply makes it more complete. It is still possible to do POST another way and Windows programs can always drive Internet Explorer via COM or DDE, but I think POST in webbrowser would make a nice addition for the future.
Logged In: YES user_id=6380 I still don't understand why you would need to do this. urllib supports POST. But the webbrowser module directs the user's browser to a website. Can you give an *example* of when you need this? Otherwise I'll just reject it -- I don't think this is possible anyway for most browsers except IE.
Logged In: YES user_id=228025 If you want to direct a user's browser to a web page that is the result of a POST. As I stated earlier, it is not always possible to get to the same page using GET. If this isn't possible on other browsers on other platforms then it might be best to just note this feature request in the webbrowser docs so that the issue isn't raised again. As mentioned earlier, a Windows script can always drive IE via COM or DDE if needed.
