IssueTracker

Don't hold your breath, I don't expect this to happen any time soon.

FWIW, your server configuration is arguably incorrect as HTTP requires that GETs be
idempotent.

[Comment deleted]

My server configuration has little to do with it.

Careful reading of RFC2616 reveals that HTTP does not _require_ GETs to be idempotent:
"Methods can also have the property of "idempotence" in that (aside from error or
expiration issues) the side-effects of N > 0 identical requests is the same as for a
single request. The methods GET, HEAD, PUT and DELETE share this property"

Note "CAN also have" and not "MUST also have" or even "SHOULD also have."  

Possibly, if your argument was correct, requests for Google's own show_ads.js would
be required to always return the same ad.

I think idempotence makes a lot more sense for requests for static content and not
for dynamic content.

"the GET and HEAD methods SHOULD NOT have the significance of taking an action other
than retrieval", so, yes, it's OK for your server to return different data each time,
but it's also OK for the browser to transparently request those requests multiple
times without any additional user interaction.

On top of that, in a mobile environment, you need to assume that connections will get
lost, i.e. that any download is likely to happen over multiple connections.

Anyway, like I said above, this is a very significant feature that isn't likely to
get implemented any time soon... unless you decide to contribute, of course, in which
case you're welcome to discuss the implementation constraints on the android-platform
mailing list.

[Comment deleted]

I'd like to add that issue goes beyond standards compliance, being able to count the
number of downloads correctly, or serving appropriate dynamic content.

If the mobile application is used with cloud computing services, then developers have
to deal with limits on the number of requests and bandwidth.  If we're lucky, these
limits are soft and we can pay for the overage.  This browser issue will help push
the developers closer to the limits with the extraneous requests.

None of the other browsers exhibit this double-download behavior.  I fully appreciate
the difficulty of fixing this problem, but nonetheless believe it to be a bug.

I get your point about interrupted connections, and will restructure the code to work
differently.

But there's a remarkable difference between a small fraction of intermittent wireless
connections that may lead to retries and a guaranteed 2x blowup in the number of GET
requests to content-generating scripts that happens by design.

It's definitely not a bug, it's working exactly as designed. We explicitly split the
download manager away from the browser for a variety of reasons, an the case of
double downloads was well understood and accepted as part of the design.

I just came across this issue.  How does this apply when talking about POST instead
of GET?  I'm struggling with a server that has files available for download.  To
access those files, you must be logged in, so there's a cookie and/or session ID
involved.  To access the download content, a form is POSTed, and the content is
returned through an attachment (Content-Disposition: attachment).

However, with the "double download" thing happening, the download manager doesn't
pull the actual content, because it doesn't re-POST to the URL.  It looks like the
browser app correctly POSTs, but the download manager then tries to GET.  Since the
remote server is not seeing all of the proper form fields, it returns a default HTML
page instead of the expected attachment content.  This is the same action the web
server would take if you are not logged in and attempt to download the content.

In this case, I'm referring to a server that I don't control, so I don't have the
ability to influence the way the web app is architected.  I have to rely on the
browser to handle the download properly.

What's the proper way to handle this?

The download manager doesn't support POST - such downloads can't be initiated from
the browser. That's an open issue.

This and 1780 are fundamentally the same issue (that the browser needs to hit the
server to determine that something is a download, and that the download manager has
to separately contact the server)

This is absolute nonsense that this is by design. I have a secure download application that lets you only download the file once. Unfortunately on Android Mobile it hits it twice so it always fails since the file is already deleted. Who's brilliant idea was it to do this on purpose.. i swear i hate programmers sometimes.