I posted this on android-platform a while ago, but didn't see any response, so I'll try here.
I've been combing through the browser app's source trying to make sure I understand this, and I think I do. I found http://code.google.com/p/android/issues/detail?id=1978 which details a question about the way that the download manager "double downloads" a URL. I have a slightly different question. I'd like to develop an application that interacts with a web application (that I don't control) that requires a login to download specific files. Specifically, I'd like my users to be able to click a button in the browser, have the browser download the file, and then start my application to use that file. In order to actually download the files, a form must be POSTed to a URL. If the URL is accessed through a GET request, the application returns an error page. If certain form fields are missing from the POST request, the same error page is returned. The only way to get to the content is to POST to the URL with the proper form fields and cookies, and the server then returns a page with a specific mimetype and Content-Disposition: attachment. Desktop browsers handle this fine, because they see the response from the POST and immediately ask the user to save the attached file. Android's browser, however, does not do that. The initial POST from the browser goes just fine, and then the URL, content disposition, mimetype, and other header information are handed off to the Download Manager. From what I've traced, this ultimately ends in an insert to a DownloadProvider, which launches a thread to handle the actual HTTP connection. That thread seems to be only capable of a GET, which does not work in the scenario I detailed above. I understand that certain architectural decisions were made that support the "double download." Was this POST scenario considered? Is this something that could possibly be patched in a future release of the browser? I'll consider working on the patch myself, but I'd hate to put in a ton of time to find out later that this doesn't fit within the vision of the Android browser as a whole. It looks like a fairly complicated patch too, since I think it'd mean modifications to the DownloadProvider, its underlying database, and the browser in order to pass the POST parameters all the way down to the point where the DownloadThread is ready to go get the file. Thanks, -brian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
