IssueTracker

Digging around a bit, it appears WebKit itself doesn't handle authentication at all.
 Instead, it would appear on Android that the package org.apache.http.auth does this.

It's definitely not passing through the information.  Here's a snippet from my Apache
log:
---
192.168.10.199 - - [20/Nov/2008:20:14:37 -0600] "GET /file.txt HTTP/1.1" 401 401 "-"
"AndroidDownloadManager"

I would also like the ability to use gcloud to list existing API keys and restrictions applied to them. Although I don't expect the ability to re-create a key with the same value in a different project, I would at least like to be able to list what keys exist in a given project for backup and/or other purposes.

Any update on this issue?

Apparently there isn't anything else to say concerning this is there.

Soooo, yeah, just confirmed this on several devices. It would be really nice to be
able to access my server from my phone. That is kind of why I set it up.

Maybe it would work on another browser besides default? Anyone know?

So I devised a workaround for this issue if anyone is interested. However, you have
to allow free access from any browser that broadcasts itself as the
AndroidDownloadManager to the folders you want your phone to be able to download.
Here is what you need to enter in the httpd configuration file in apache:

SetEnvIf User-Agent ^AndroidDownloadManager let_me_in
<Directory "FolderWhereYourStuffIs">
    Order deny,allow
    Deny from all
    Allow from env=let_me_in
    require valid-user
    Satisfy any

I did this for every individual folder, because there are some folders in my root
directory that I do not want to put online and if you put this in the root directory
then you have to share everything because of the satisfy any directive. This
directive will be applied to every sub-folder, and there is not way to stop it.
(Maybe a limit phrase, but I am not advanced enough to figure that out).

@hunterpritchett:
I tried it with the dolphin browser too and it doesn't work (without the modification
suggested later). My impression is that there is one download manager which handles
file downloads and this is used by dolphin too. When I clicked on the file, dolphin
showed up the download history used by the default browser.

I have posted this problem some time ago also on the google nexus one forums:
http://www.google.com/support/forum/p/android/thread?tid=2a6aeb6741c24a7a&hl=en
where I also add that the credentials are also not passed to any other program. So
even if I download a playlist from the password protected site and I try to play it,
it does not get played as the authentication of the browser is not passed on to the
media player.

It's certainly an issue and I would love to have a solution too, if anyone is
listening :). Apart from a few bugs, very happy with the N1.

Opera seems to be able to download files just fine.  It uses it's own built-in
downloader.  I have the same Apache setup and the same difficulties with the Webkit
browser, but Opera has no difficulties.

Awesome guess my workaround is only necessary for the other browsers then. I have the
opera browser anyway, so that's great.

The Steel browser also has its own download manager, therefore it does not suffer
from this bug.

My question is: how can this NOT be considered a defect?  Browsing and downloading
from sites that require authentication is a pretty basic feature of any browser.  It
seems that the decision to keep the browser and download manager entirely separate,
while admirable, has led to a lot of problems (#1780, #7328, #3948, maybe #3492,
...).  I think the download manager should be able to accept a connection object from
the browser, and begin the download based on the existing connection.

On my server, I'm using digest authentication.  This causes Android to send THREE
requests to my server: somehow the browser loses track of the authentication
information when it detects a download, connects once, prompts for the username and
password, then connects again.  After all that, the download manager connects, and
doesn't even attempt to send any authentication headers (so of course, it fails).

This defect has not been fixed in Froyo. Please fix this bug, as it prevents me from playing music from my server.

jnylen: Consider it a defect. The bug has been assigned to an Android engineer.

I've run into the same problem with my Nexus One running android 2.2.  After basic http authentication, I can download html files with the android browser but not mp3 files.  My iPod Touch running mobile safari (also webkit based) downloads the mp3s without difficulty.  I hope Google will fix this soon.   I posted issue 36919571 before I found this issue, #1353, had been submitted.

I would like to be able to automate this using either gcloud or REST; the latter being useful for building terraform scripts.

We experienced the same problem with an .apk file. We wanted to distribute a test apk via secured web server using https basic authentication. About half of our testers were not able to download the file.

It would definitely be nice to be able to send clients links to applications and have them be protected with a password. Please fix this.

Some news about this?

Still waiting for a fix for this. I cant believe it doesn't work...

Still busted in Gingerbread.

This will also screw up invoking the native video player via HTML5 if the page is behind http authentication.

Some news about this? It is so difficult to fix?

Still not fixed in HoneyComb...

I cam across this problem trying to connect to Logitech SqueezeboxServer's "stream.mp3" which I had for obvious reasons sat behind basic auth.
At first I thought it was an issue with "Streaming Media Player" as after asking for my username and password and accepting them - it then asks me what app to use - Streaming media player than complains it cannot play the file.

I have been through countless apps on the market trying to find one which will allow me to connect to an mp3 stream with basic protection enabled and I have not found one. It is more annoying knowing that the built in Streaming media Player could handle this just fine if it actually got passed the necessary credentials from the default browser.

I emailed them about this and it didn't seem like a priority and likely won't be fixed for a while (possibly not even in the next major OS version). Insane!

Conspiracy theory:  Maybe Google doesn't want to create this feature, since it would allow an easy way to stream media from a variety of secure existing & home-brew servers.  They probably have their own wishes for streaming media, and it is easy to imagine why they would want to keep control over this use of Android (advertising...).  One way around this (for those wishing to do so) would be to code up a server that would create temporary use-once insecure public URL's that are generated on-the-fly by re-direction.  I'm not an expert, and I'm just speaking off the cuff, but it maybe possible with PHP?

Of course there are various other ways to secure a file... in fact http auth is not often used these days...
but we shouldn't have to work around this issue!

Your conspiracy theory seems farfetched though.  I think laziness is more likely.

Still not fixed on Honeycomb. Makes it difficult to access private content. Seriously Google.

Very annoying problem on my N1 (2.3.3)...Now using Firefox for downloading files like that