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"

Example 2. Trying to use callback parameter. Init is loaded, main javascript file is loaded too. But not working, exception screenshot is in attach.

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 don't wish to be rude, but this remains a significant problem.

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.

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

Would be nice to have this issue addressed...

Prevents distributing beta versions of apps on a simple password protected website.

Occurring on:
- Acer ICONIATAB
- Motorola XOOM Tablets:

When downloading an image or PDF from a location which uses HTTP basic, the download fails.

Analyzed with wireshark:
- A first request with the correct credentials is issued, the resource is retrieved correctly 200 OK. (User-Agent: Mozilla/5.0 (Linux; U; Android 3.0.1; de-de; A500 Build/HRI66))
- A second request on the same location WITHOUT the "Authorization" HTTP header is issued with the User-Agent: AndroidDownloadManager. Naturally this request fails with a 401.

Someone posted that Dolphin HD uses the built in download manager. I have dolphin hd 5.1.0 and it has its own download manager which will work with basic auth. So dolphin hd is a viable workaround, but I can't believe they haven't fixed this yet!

I am also using Dolphin HD 5.1.0 but it seems to use the andriod download manager and it does not work with basic auth for me...  Bummer!  Is this a setting or an add-on?

"enhancement"?? this is not a frivolous bug - it BREAKS the functionality of simple private websites (like calibre) and is most certainly a defect, whether or not it is labeled as such.

Jean-Baptiste,

Please read comments 19 and 21 on this issue.  Googler cccandroid agrees with us that this is a defect and NOT an enhancement.

I believe that the objection was to the googler un-marking this as a
defect and re-marking it as an enhancement.

 danielbh...@gmail.com... Regarding dolphin's download manager, I didn't find any setting to turn it on or off (and I have a default install on an x2 running gingerbread) but dolphin support (support@dolphin-support.com) seems pretty responsive even though english isn't their first language...

This is certainly a defect. Isn't there an RFC that says what features should absolutely be included in a browser?

Here we go again. It's a defect, not an enhancement, no matter what the title says.

Basic Auth was introduced in RFC 2617 as an addition to HTTP 1.1 in 1999.  It is not a required feature, but virtually every browser since then has included it as a standard feature.  It is an abysmal oversight that the Android browser lacks this feature, for which Google and the Android team should be ashamed.  (shame, shame).

Here's how I typically categorize bugs.

Enhancement: new functionality that doesn't exist yet.
Defect: existing functionality that someone wrote, but it's broken and needs to be fixed.

For example, adding cosh() to the Calculator app would be a feature, not a bug.  :)

The current behavior is within the scope of RFC 2616:  "The client MAY repeat the request with a suitable Authorization header field."

I find it introduced in RFC 1945 circa may 1996-- HTTP/1.0... http://www.ietf.org/rfc/rfc1945.txt 

Abysmal indeed.

Someone "wrote" something,  because as it stands a file tries to download and the user is left with a confusing "download unsuccessful" message-- as if something were broken. If it returned a proper error message ("oops. I don't do that yet!") That'd be one thing. If a section of obvious basic functionality code never got written,  and as ait reault the app does something that makes no sense to the user then that makes the app buggy. Is fixing a bug an "enhancement?" Technically yes. Is this a request to fix a bug or add functionality? Yes. Which will get higher priority from someone who doesn't take the time to look into it fully? We would like it to be fixed someday, thus the reason we like it marked as a "defect."

Broken support for HTTP is *not* new functionality. Standard
functionality for a HTTP client being broken in Android is in no way
"new functionality that doesn't exist yet", it is broken functionality
that has been having a very real, very negative consequences for many
developers.

We cannot file a bug report on your faulty bug categorization
criteria. I apologize for my rudeness but it takes a large amount of
self-deception or lack of perspective to peg this as anything other
than a defect. Claiming otherwise and sticking to a clearly misapplied
label is heavy-handed and inappropriate. This is a defect. Please fix
your bug categorization criteria.

"Enhancement: new functionality that doesn't exist yet." ?
Lipstick on a pig.

Many devs need HTTP Basic in order to deliver beta APKs and other content without fully exposing it to the world.  For basic file delivery it's too much work to implement full session cookie based auth, SSL, etc.

Sure, it's not a required part of HTTP, but what other major client doesn't support it?

So glad to see all of the attention this issue is getting since it is so ridiculous that it is not fixed. I emailed the person assigned to this once before and they didn't think it was even too much of an issue stating that it might be fixed in the next release, but if not the one after that. We currently have to temporarily remove password protection (http auth) for our staging environment for a MAJOR corporation on occasion to properly test HTML5 Video on Android due to this bug. I feel stupid explaining this risk to the client and they also don't even believe something this elementary can be wrong with Android.

There are so many places basic auth is completely appropriate. Besides my own personal encounters and uses, I point the reader to digital blasphemy dot com, a very popular and successful wallpaper site with a subscription model and user logins for some content. It's just wallpapers, not national security. Basic auth is simple to implement and doesn't pose a genuine security risk to the site owner.

His punishment for this is dealing with all the user support emails asking why his member downloads don't work on android phones and tablets. He has to tell users that the solution is to ditch the builtin browser and get "one that works right." He doesn't tell them that their browser "lacks functionality" or "is missing an enhancement." It's DEFECTIVE.

See?

Besides all that, my iphone users are laughing at me. "Your factory browser doesn't support basic authentication?! Ha!"

Not an enhancement. This is a bug. Literally EVERY other major smartphone is not burdened with this bug. Please fix it google. It's REALLY not that much to ask.

This is getting to the point where you have to think it's just some developer's passive aggressive way to tell everyone that basic auth is not "proper security", especially in the wake of all the recent hacking. While true to an extent, people don't use basic auth to secure government secrets or plain text files filled with people's social security numbers (I hope not); many times it's just simple things like personal pictures, a pre-release website selling pink plush kittens that you don't want every John Doe to easily stumble into, or small bits of beta code that you don't want anyone to see.

For those things, we just want a simple speed bump for the common non-hackers, and can't be arsed to install 2 rows of stanchions, multiple level gate houses with rotating, patrolling armed guards and drug sniffing dogs armed with state of the art lasers on their heads.

Re. comment 60:

I'd argue that HTTPS + digest authentication is actually pretty good from a security standpoint.  I use this scheme on my server but it doesn't work for Android.  It's not just basic auth that's broken.