Assigned
Status Update
Comments
mr...@gmail.com <mr...@gmail.com> #2
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.
Instead, it would appear on Android that the package org.apache.http.auth does this.
mr...@gmail.com <mr...@gmail.com> #3
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"
log:
---
192.168.10.199 - - [20/Nov/2008:20:14:37 -0600] "GET /file.txt HTTP/1.1" 401 401 "-"
"AndroidDownloadManager"
ju...@gtempaccount.com <ju...@gtempaccount.com> #5
Any update on this issue?
la...@gmail.com <la...@gmail.com> #6
Apparently there isn't anything else to say concerning this is there.
hu...@gmail.com <hu...@gmail.com> #7
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.
able to access my server from my phone. That is kind of why I set it up.
hu...@gmail.com <hu...@gmail.com> #8
Maybe it would work on another browser besides default? Anyone know?
hu...@gmail.com <hu...@gmail.com> #9
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).
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).
ma...@gmail.com <ma...@gmail.com> #10
@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.
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:
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.
ih...@gmail.com <ih...@gmail.com> #11
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.
downloader. I have the same Apache setup and the same difficulties with the Webkit
browser, but Opera has no difficulties.
hu...@gmail.com <hu...@gmail.com> #12
Awesome guess my workaround is only necessary for the other browsers then. I have the
opera browser anyway, so that's great.
opera browser anyway, so that's great.
jn...@gmail.com <jn...@gmail.com> #13
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).
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).
hu...@gmail.com <hu...@gmail.com> #14
This defect has not been fixed in Froyo. Please fix this bug, as it prevents me from playing music from my server.
cc...@gmail.com <cc...@gmail.com> #15
jnylen: Consider it a defect. The bug has been assigned to an Android engineer.
[Deleted User] <[Deleted User]> #16
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.
ph...@gmail.com <ph...@gmail.com> #18
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.
mt...@gmail.com <mt...@gmail.com> #19
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.
ga...@gmail.com <ga...@gmail.com> #20
Some news about this?
sh...@gmail.com <sh...@gmail.com> #21
Still waiting for a fix for this. I cant believe it doesn't work...
an...@gmail.com <an...@gmail.com> #22
Still busted in Gingerbread.
mt...@gmail.com <mt...@gmail.com> #23
This will also screw up invoking the native video player via HTML5 if the page is behind http authentication.
ka...@gmail.com <ka...@gmail.com> #24
Some news about this? It is so difficult to fix?
mt...@gmail.com <mt...@gmail.com> #25
Still not fixed in HoneyComb...
mo...@gmail.com <mo...@gmail.com> #26
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.
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.
mt...@gmail.com <mt...@gmail.com> #27
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!
jc...@gmail.com <jc...@gmail.com> #28
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?
al...@gmail.com <al...@gmail.com> #29
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.
but we shouldn't have to work around this issue!
Your conspiracy theory seems farfetched though. I think laziness is more likely.
th...@shadowpedia.info <th...@shadowpedia.info> #30
Still not fixed on Honeycomb. Makes it difficult to access private content. Seriously Google.
ke...@googlemail.com <ke...@googlemail.com> #31
Very annoying problem on my N1 (2.3.3)...Now using Firefox for downloading files like that
dr...@gmail.com <dr...@gmail.com> #32
Would be nice to have this issue addressed...
ia...@gmail.com <ia...@gmail.com> #33
Prevents distributing beta versions of apps on a simple password protected website.
iv...@gmail.com <iv...@gmail.com> #34
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.
- 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.
je...@gmail.com <je...@gmail.com> #35
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!
da...@gmail.com <da...@gmail.com> #36
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?
jb...@google.com <jb...@google.com>
br...@gmail.com <br...@gmail.com> #37
"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.
jn...@gmail.com <jn...@gmail.com> #38
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.
Please read comments 19 and 21 on this issue. Googler cccandroid agrees with us that this is a defect and NOT an enhancement.
ab...@gmail.com <ab...@gmail.com> #39
I believe that the objection was to the googler un-marking this as a
defect and re-marking it as an enhancement.
defect and re-marking it as an enhancement.
je...@gmail.com <je...@gmail.com> #40
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?
This is certainly a defect. Isn't there an RFC that says what features should absolutely be included in a browser?
cp...@gmail.com <cp...@gmail.com> #41
Here we go again. It's a defect, not an enhancement, no matter what the title says.
jc...@gmail.com <jc...@gmail.com> #42
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).
js...@android.com <js...@android.com> #43
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."
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."
je...@gmail.com <je...@gmail.com> #44
I find it introduced in RFC 1945 circa may 1996-- HTTP/1.0... http://www.ietf.org/rfc/rfc1945.txt
Abysmal indeed.
Abysmal indeed.
je...@gmail.com <je...@gmail.com> #45
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."
ab...@gmail.com <ab...@gmail.com> #46
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.
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.
jc...@gmail.com <jc...@gmail.com> #47
"Enhancement: new functionality that doesn't exist yet." ?
Lipstick on a pig.
Lipstick on a pig.
cp...@gmail.com <cp...@gmail.com> #48
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?
Sure, it's not a required part of HTTP, but what other major client doesn't support it?
mt...@gmail.com <mt...@gmail.com> #49
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.
je...@gmail.com <je...@gmail.com> #50
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!"
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!"
jo...@4act.com <jo...@4act.com> #51
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.
he...@gmail.com <he...@gmail.com> #52
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.
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.
jn...@gmail.com <jn...@gmail.com> #53
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.
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.
ch...@gmail.com <ch...@gmail.com> #54
Even basic authentication is perfectly fine with SSL underneath. This is most likely a simple bug. All HTTP headers are passed into the download manager's HTTP request and someone forgot the "Authorization" header. Should be a one line fix.
di...@gmail.com <di...@gmail.com> #55
[Comment deleted]
al...@gmail.com <al...@gmail.com> #56
This is insane. It's been nearly FOUR years now since this was first reported and it is STILL not fixed! What is going on at Google?! This bug prevents use of not only simple SLL/digest websites for a wide variety of purposes but it also stops many commercial home media servers from working.
This is definitely well into "conspiracy theory" territory. A few months delay could be incidental, but four years? Definitely deliberate and purposeful.
This is definitely well into "conspiracy theory" territory. A few months delay could be incidental, but four years? Definitely deliberate and purposeful.
ia...@gmail.com <ia...@gmail.com> #57
Checking in to confirm that the GT-P7510 Build/HMJ37 Browser (honeycomb 3.1) sends basic http auth information, but fails to hand off the authentication info to the AndroidDownloadManager. In other words, this is still broken.
The best solution I've found so far is to use Firefox, instead of the built-in browser.
The best solution I've found so far is to use Firefox, instead of the built-in browser.
ju...@gmail.com <ju...@gmail.com> #59
We already know that there are workarounds for this bug (use a different browser) but this doesn't change the fact that android is still broken after years. That's ridiculous...
sc...@gmail.com <sc...@gmail.com> #60
Would love to see a fix for this issue. I thought it could be a problem with my hardware specifically until I found this discussion.
jo...@gmail.com <jo...@gmail.com> #61
We have an intranet application that requires basic authentication. Just tried it on a newly purchased Galaxy Tab 10.1 (GT-P7510 as above), and again thought this was a problem with our application until we found this issue. Site login/authentication is required to access a variety of features in the intranet application, including file downloads (documents, zips, pdfs, images, etc.). That this is still broken seems like a cruel joke.
sp...@gmail.com <sp...@gmail.com> #62
I have this problem as well. Firefox and Opera are the only browsers that don't have the issue. Neither of those browsers show download speed. I find this extremely frustrating and it makes me miss my iPhone where everything worked perfectly.
ma...@gmail.com <ma...@gmail.com> #63
How is this not fixed after three years!? Android's browser is unusable for me.
im...@gmail.com <im...@gmail.com> #64
This issue has been addressed in Sense based roms...
si...@gmail.com <si...@gmail.com> #65
On stock Nexus-S, 2.3.6, I still see this issue.
I am trying to download an APK via the default Browser. I am challenged for credentials to display the webpage, which I provide and successfully render the page. The link to a file I am trying to download then fails with a 401. The user experience is simply a message stating "Download Unsucessful."
I would expect the default browser to be able to download the file using the same credentials provided immediately before, or at the worst, request credentials from the user. I wouldn't expect this to fail in this manner (that is, not provide the ability to respond to the challenge).
May I have an update on the progress of this issue? - specifically, if it is going to be addressed and when.
thanks
.s
I am trying to download an APK via the default Browser. I am challenged for credentials to display the webpage, which I provide and successfully render the page. The link to a file I am trying to download then fails with a 401. The user experience is simply a message stating "Download Unsucessful."
I would expect the default browser to be able to download the file using the same credentials provided immediately before, or at the worst, request credentials from the user. I wouldn't expect this to fail in this manner (that is, not provide the ability to respond to the challenge).
May I have an update on the progress of this issue? - specifically, if it is going to be addressed and when.
thanks
.s
si...@gmail.com <si...@gmail.com> #66
Update: I have a workaround (which is a custom downloader app) which works for now, however this is not the functionality I would expect from a browser. Cheers!
kr...@gmail.com <kr...@gmail.com> #67
Is there any other workaround for the use WebView in my android app ?
Is there another way of securing my files on the tomcat server that might work with the android browser ??
Is there another way of securing my files on the tomcat server that might work with the android browser ??
ev...@webstarpromotions.com <ev...@webstarpromotions.com> #68
How is this issue not fixed yet? Google is really showing it's incompetence. I bought 15 Xooms for our law firm and no one can access the password protected files on our intranet site because of this defect.
Since they haven't done anything for years I don't think they'll bother to ever fix this. Good job Google. I'll be exchanging my defective Xooms for iPads now. I hope your company fails in the worst way.
Since they haven't done anything for years I don't think they'll bother to ever fix this. Good job Google. I'll be exchanging my defective Xooms for iPads now. I hope your company fails in the worst way.
ma...@gmail.com <ma...@gmail.com> #69
Just download the dolphin browser. Its a great browser ansd it does the
trick.
trick.
la...@gmail.com <la...@gmail.com> #70
[Comment deleted]
la...@gmail.com <la...@gmail.com> #71
There are optional browsers on the market that should allow this just the stock browser doesn't but this might change with the 4.0 update.
ev...@webstarpromotions.com <ev...@webstarpromotions.com> #72
Android 4.0 doesn't come out for another month and even then it will probably be a while before the vendors start releasing the update to their devices.
I tried Dolphin browser, but it too used the download manager, so no-go there.
I tried Opera, but SURPRISE, it doesn't render my intranet site correctly, seemingly unable to handle simple jquery modal dialogs.
I've never had a good experience with Google, never close. I should have known better than to purchase a product that they had a hand in. They throw things together, put them out to the public, and almost never bother with fixing all the bugs it released with. Apple (iOS) products are MUCH better and with the way Google does business, there is always going to be competitive products that are vastly superior to Google's. Seems like they just don't care, so neither do I.
I tried Dolphin browser, but it too used the download manager, so no-go there.
I tried Opera, but SURPRISE, it doesn't render my intranet site correctly, seemingly unable to handle simple jquery modal dialogs.
I've never had a good experience with Google, never close. I should have known better than to purchase a product that they had a hand in. They throw things together, put them out to the public, and almost never bother with fixing all the bugs it released with. Apple (iOS) products are MUCH better and with the way Google does business, there is always going to be competitive products that are vastly superior to Google's. Seems like they just don't care, so neither do I.
jn...@gmail.com <jn...@gmail.com> #73
Evan: there are lots of other browsers you could try. You could also have a look at the "Download Manager for Android" app on the Market. But it sounds like you have already made up your mind and I'm not really sure why you went with Android in the first place.
Also, this issue is not fixed as of Android 4.0.3.
Also, this issue is not fixed as of Android 4.0.3.
de...@gmail.com <de...@gmail.com> #74
Why haven't you guys bothered to fix this bug? It's been over 3 YEARS.
It should be relatively simple to fix that even a mediocre developer could fix in < 1 day. A decent developer could fix the bug in a matter of hours.
Just send the authorization information correctly as defined by the HTTP specification. Every other major browser, including terrible browsers like IE6, managed to get it right.
It should be relatively simple to fix that even a mediocre developer could fix in < 1 day. A decent developer could fix the bug in a matter of hours.
Just send the authorization information correctly as defined by the HTTP specification. Every other major browser, including terrible browsers like IE6, managed to get it right.
to...@gmail.com <to...@gmail.com> #75
One question, Do you know guys how Microsoft is doing this in OWA (Outlook Web Application), they are using a generic handler "attachment.ashx" and we are able to download these attachments to Androiod although OWA is using basic authentication!!
de...@gmail.com <de...@gmail.com> #76
Microsoft must be doing something odd with their attachment.ashx -- I tried to create a similar thing on my server. The code is pitifully simple, just load the file off the disk and send it back as the response. However, Android still came up with "download failed" -- even though no 401 challenge is generated.
This is shameful. Not only has Google left the bug unfixed, they refuse to even acknowledge it as a bug and *incorrectly* categorize it as an "enhancement" / feature request.
This is shameful. Not only has Google left the bug unfixed, they refuse to even acknowledge it as a bug and *incorrectly* categorize it as an "enhancement" / feature request.
ma...@gmail.com <ma...@gmail.com> #77
Still does not work on ICS with Dolphin HD or even Chrome Beta.
While there may be issue management politics that allow calling it "an enhancement", it's strategically boneheaded to allow it to languish as long as it has.
While there may be issue management politics that allow calling it "an enhancement", it's strategically boneheaded to allow it to languish as long as it has.
dv...@gmail.com <dv...@gmail.com> #78
This is really frustrating... can anyone please, at least provide some decent workaround - even if it is on the server side? maybe add some headers? maybe try forced authentication or something??
st...@gmail.com <st...@gmail.com> #79
Yarp.
Broken form e too, of course. Waiting for a fix... Android 2.3.6 on a Motorola Milestone X2.
Broken form e too, of course. Waiting for a fix... Android 2.3.6 on a Motorola Milestone X2.
jo...@gmail.com <jo...@gmail.com> #80
unbelievable!
we spent quite a lot of time debugging our applications thinking something wrong.
And it's broken for years? Just unbelievable.
Well, it's free and open source!
Can't do much about it!
we spent quite a lot of time debugging our applications thinking something wrong.
And it's broken for years? Just unbelievable.
Well, it's free and open source!
Can't do much about it!
de...@gmail.com <de...@gmail.com> #81
You get what you pay for ;-)
df...@gmail.com <df...@gmail.com> #82
Droid Razr Maxx - Same Problem cant download files.
Unbelievable that this issue has received no attention at all.
Unbelievable that this issue has received no attention at all.
mt...@gmail.com <mt...@gmail.com> #83
When colleagues ask me why I don't recommended Android I just send them a link to this bug.How difficult can it be to add the proper headers to an http request? Most pre production environments are protected by http auth and this bug completely screws up most video players in a URL behind http auth. I feel stupid every time I have to explain to a client why video playback doesn't work at a staging URL. This is a bug that mostly inconveniences developers rather than end users and that's why Google has no interest in fixing it.
ru...@gmail.com <ru...@gmail.com> #84
This is so weird to see this ISSUE open for the past 4 years !! Please resolve this on priority.
dr...@googlemail.com <dr...@googlemail.com> #85
i tried a workaround using http://username:password@example.com/private but that doesnt do the trick either. i got laughed at today by an iphone user.
ki...@gmail.com <ki...@gmail.com> #86
Still seeing it on a Galaxy Nexus with ICS 4.0.3. Starting to think it's intentional.
cr...@gmail.com <cr...@gmail.com> #87
Tested on Samsung Galaxy S II and Motorola Milestone with Cyanogenmod Gingerbread, the issue remains.
On HTC EVO 3D (Gingerbread) the issue has been solved (by HTC?!).
On Samsung Galaxy S it has been solved (but for some reason the browser attempts 2 downloads: the first one is without auth data, the second is correct).
On HTC EVO 3D (Gingerbread) the issue has been solved (by HTC?!).
On Samsung Galaxy S it has been solved (but for some reason the browser attempts 2 downloads: the first one is without auth data, the second is correct).
[Deleted User] <[Deleted User]> #88
I bought a iPhone 2 years ago because of this issue. I stay subscribed to this thread as it reminds me that my choice was the right one to make. Now whenever my friends ask me why i didn't buy android, I load up this email thread and we all get a chuckle. Cheers.
ia...@gmail.com <ia...@gmail.com> #89
You can download a browser that works e.g. Opera.
st...@gmail.com <st...@gmail.com> #90
I've tried a number of browsers. Firefox seems to be the most
friendly on my phone, but it takes a little time to start compared to
whatever browser it is that android comes with.
Not trying to start a browser war, but all the non-default browsers
have added functionality that, while cool and occasionally useful,
detract from the browsing experience in general. If they just added
http authentication to the default browser, that'd be slick.
friendly on my phone, but it takes a little time to start compared to
whatever browser it is that android comes with.
Not trying to start a browser war, but all the non-default browsers
have added functionality that, while cool and occasionally useful,
detract from the browsing experience in general. If they just added
http authentication to the default browser, that'd be slick.
ia...@gmail.com <ia...@gmail.com> #91
Yes, it's no excuse at all but there seems no action to resolve this despite ~100 comments on this thread.
mt...@gmail.com <mt...@gmail.com> #92
I've emailed jsharkey@android.com about this and you should all do the same.
wo...@gmail.com <wo...@gmail.com> #93
This issue also in 4.0 ics.
ka...@gmail.com <ka...@gmail.com> #94
Ridiculous, we use ssl with basic authentication to allow our company users to download secure files from our web server and all the android devices have the same issue with downloading. I just don't think google realizes how my corporate business they are loosing because of such small issues. Not surprised most companies are buying ipads instead of android devices. Google, catch a wake up !!!!
di...@gmail.com <di...@gmail.com> #95
ARE YOU KIDDING ME?!?!?!?!?!?!?!lksfjhsfdlkjdsflkjdsflkjsdflkjdsf
How is this STILL an issue after 5 years?
Is the Download Manager open source?
How is this STILL an issue after 5 years?
Is the Download Manager open source?
sy...@gmail.com <sy...@gmail.com> #96
[Comment deleted]
de...@gmail.com <de...@gmail.com> #97
bump, I run my own authenticated music server and just bought a one x, I'm screwed.
pk...@gmail.com <pk...@gmail.com> #98
Surely this is taking the pish. All browsers support it but are left dead in the water because you can't download anything.
I would recommend everyone uses Opera which thankfully has it's own manager. Maybe then Google will take notice of this bug and fix it?
I would recommend everyone uses Opera which thankfully has it's own manager. Maybe then Google will take notice of this bug and fix it?
sh...@gmail.com <sh...@gmail.com> #99
This is a problem with downloads from the browser in general, not just 401 auth. I have a process that pushes content the browser to download a pdf or a .zip file and neither will work on the android platform. I started with v2 and now i'm on ics 4.04 and it doesn't work. The default browser or chrome beta ... neither. My daughter has an iPhone and it works fine. I can download from any browser on my desktop and laptop and it works fine. Also seems to work in the Opera mobile browser on ics 4.04. Google, will you please fix this issue!?
nu...@gmail.com <nu...@gmail.com> #100
Google... you should really fix this!
The company I work for, has just bought almost 200 tablets with android 4.0.3.. and we must tell our users to install opera in order to download from our server files protected with https + basic authentication!!
Four years + over 100 complaints (just here on this page!) and this is not yet fixed? Unbelieveble!
The company I work for, has just bought almost 200 tablets with android 4.0.3.. and we must tell our users to install opera in order to download from our server files protected with https + basic authentication!!
Four years + over 100 complaints (just here on this page!) and this is not yet fixed? Unbelieveble!
al...@gmail.com <al...@gmail.com> #101
[Comment deleted]
sh...@gmail.com <sh...@gmail.com> #102
Follow up to comment 107. I now have Jelly Bean 4.1.1 and it still does not work. I can get pdf and zip downloads to work using the Opera browser as I think it uses a different download manager. I don't think its the web browser that comes with Android or the Chrome browser for Android, I think its the download manager. I doesn't know what to do with the header response from the server and the download is unsuccesful, every single time. If I use the Opera browser it works fine everytime.
gr...@emsley.ca <gr...@emsley.ca> #103
This is a pretty major issue for using android devices with sharepoint and other intranet sites.
ma...@gmail.com <ma...@gmail.com> #104
This is really silly. Basic Auth is a fundamental means of authenticating a user. It is used inside corporate environments extensively. Perhaps the developer would suggest a functional means of authenticating a user that the download manager would support. When will Google decide to support the IT dept?
mv...@gmail.com <mv...@gmail.com> #105
This is ridiculous. This bug needs to go viral.
ne...@gmail.com <ne...@gmail.com> #106
Thanks Google for wasting my time. Apparently, you don't care about solving issues.
ne...@gmail.com <ne...@gmail.com> #107
Btw, two things:
1. This is broken also for IIS "Windows authentication"
2. Original poster - I suggest to create a new ticket with a name that doesn't imply enhancement, such as "Chrome downloader is breaking authentication standards", and mark this one as duplicate of the new one.
1. This is broken also for IIS "Windows authentication"
2. Original poster - I suggest to create a new ticket with a name that doesn't imply enhancement, such as "Chrome downloader is breaking authentication standards", and mark this one as duplicate of the new one.
v0...@gmail.com <v0...@gmail.com> #108
Thanks for the info that Opera is working fine. I'm switching now :-)
[Deleted User] <[Deleted User]> #109
This isn't an enhancement, it's a major problem that needs to be fixed. Any attempt to download a protected file just fails without an explanation. I've been advising clients to use Firefox or Opera to download protected files instead.
er...@gmail.com <er...@gmail.com> #110
How frustrating!
In the meantime, while Google still lets their society crumble away in frustration, I need a temporary solution, so I tried Opera, and it works, but not without efforts.
Because the procedure to play a mp3 file is too long, and illogical, since after "clicking" on my server's mp3 link, I must:
1 select from "Complete action using..."
2 press "open"
3 chose between "Adobe reader" and "file manager"
(does this question imply that I have the wrong mime header on my IIS server?) I chose File manager which gets me into my download folder
4 chose my downloaded mp3 and finally
5 choce my player
What can I do to simplify this?
In the meantime, while Google still lets their society crumble away in frustration, I need a temporary solution, so I tried Opera, and it works, but not without efforts.
Because the procedure to play a mp3 file is too long, and illogical, since after "clicking" on my server's mp3 link, I must:
1 select from "Complete action using..."
2 press "open"
3 chose between "Adobe reader" and "file manager"
(does this question imply that I have the wrong mime header on my IIS server?) I chose File manager which gets me into my download folder
4 chose my downloaded mp3 and finally
5 choce my player
What can I do to simplify this?
al...@lab.underwares.org <al...@lab.underwares.org> #111
How is this not fixed yet? This is fairly horrible, and a serious defect.
How does whoever got assigned this in 2008 sleep at night?
Distributing, say, apk archives with basic auth and SSL isn't an uncommon scenario, as far as I know - now I'm going to have to perfom serious dirty MacGyvered workarounds because the download manager doesn't handle auth. I really don't feel like I should have to do this.
How does whoever got assigned this in 2008 sleep at night?
Distributing, say, apk archives with basic auth and SSL isn't an uncommon scenario, as far as I know - now I'm going to have to perfom serious dirty MacGyvered workarounds because the download manager doesn't handle auth. I really don't feel like I should have to do this.
an...@gmail.com <an...@gmail.com> #112
[Comment deleted]
an...@gmail.com <an...@gmail.com> #113
I have come across this bug a number of times and thought it because I was doing something wrong, but now that I see it's a bug, I guess I can only wait for a fix. I'm hoping it will be sooner than later as the organization I work for really needs this fix in place.
ph...@gmail.com <ph...@gmail.com> #114
Please Google, fix it! This is ridiculous!
Basic Authentication over HTTPS is secure and easy to handle - it is a MUST HAVE for ANY browser!
Come on! Please!
Basic Authentication over HTTPS is secure and easy to handle - it is a MUST HAVE for ANY browser!
Come on! Please!
de...@gmail.com <de...@gmail.com> #115
Can't believe it's been this long without getting fixed. Basic HTTPS auth is not rocket science. All the browsers you can install to your Android device can handle it; why can't the builtin browser? Extremely annoying. This priority shouldn't be medium. It should be high!
th...@gmail.com <th...@gmail.com> #116
Every one here talk about "browser". It's not the point. Since the DownloadManager service is the "correct" way for any application to download a file for the user, i think that not supporting any authentication should be considered as a bug.
From reference documentation of DownloadManager class: " taking care of HTTP interactions and retrying downloads after failures or across connectivity changes and system reboots"
I consider HTTP Basic & Digest authentication as "HTTP interactions".
After 4 years, there is no notice in the documentation about this "missing feature".
Please fix DownloadManager or documentation...
From reference documentation of DownloadManager class: " taking care of HTTP interactions and retrying downloads after failures or across connectivity changes and system reboots"
I consider HTTP Basic & Digest authentication as "HTTP interactions".
After 4 years, there is no notice in the documentation about this "missing feature".
Please fix DownloadManager or documentation...
ad...@gmail.com <ad...@gmail.com> #117
So have we effectively determined that this is a competency issue at Google? If there are plenty of resources, knowledgeable developers, and willing contributors, this should not be something that takes this long to correct and generate this many complaints. If the current Google staff in charge of this bug are not delivering results to a clearly non-functioning aspect of the DownloadManager, they need to be released from their positions or given more rudimentary tasks better suited for their skill sets. Unless Google can provide the community with a proper explanation, they deserve to lose every bit of business they are losing as a direct result of this disservice they are doing their customers. I can't fathom what type of mismanagement is occurring that permits employees to mislabel defects so as to not be required to address them with proper priority. Again, I firmly believe that this is merely an issue of incompetence and request this thread be escalated as a result.
Thank you.
Thank you.
st...@gmail.com <st...@gmail.com> #118
Have the same problem, HTTP authenticated download. Fails all the time, chrome, dolphin, standard browser doesn't matter.
Device Samsung S3 presumably with ICS, I am new to android.
Device Samsung S3 presumably with ICS, I am new to android.
mo...@gmail.com <mo...@gmail.com> #119
[Comment deleted]
bi...@gmail.com <bi...@gmail.com> #120
ma...@gmail.com <ma...@gmail.com> #121
Samsung Galaxy TAB 2 7.0 - Android 4.0.3 -> Failed to download PDF from password protected authenticated web folders on Apache web server. I can't believe Android is so buggy for so long ??? Now I see I should buy iPad.
bo...@gmail.com <bo...@gmail.com> #122
Okay,
Firefox world, but the main issue there is that the User Agent changes, example:
standard android safari:
Mozilla/5.0 (Linux; U; Android 2.3.5; en-us; F-05D Build/V20R29A) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
and firefox:
Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0
what happens then, in my case, is that I fail to get the mobile device model (in my case a nice DoCoMo Fujitsu 05D "F-05D"), and then the pages, and content which I am serving break (meta viewport also does not work right in firefox), with bad format. (pix/video width-height, etc)
The way I see it, the sfari browser, and the download manager are 2 different puppies, and it maybe that these googleites are so much into object oriented lunacy, that they consider passing username/password from one object to another a "security risk" (i.e. memory sniffable). With a probably only way to solve the issue being to integrate the browser and download manager (I have no clue why they have to call an external download manager to handle a file which is already in memory loaded by the browser, yet another lunacy).
However, the easiest would be to add basic auth functionality to the download manager, so it "re-asks" you for a username/pass if needed, and voilla, only needs to remember it after a reboot.
C'mon google, 4-5 years already wth !
Firefox world, but the main issue there is that the User Agent changes, example:
standard android safari:
Mozilla/5.0 (Linux; U; Android 2.3.5; en-us; F-05D Build/V20R29A) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
and firefox:
Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0
what happens then, in my case, is that I fail to get the mobile device model (in my case a nice DoCoMo Fujitsu 05D "F-05D"), and then the pages, and content which I am serving break (meta viewport also does not work right in firefox), with bad format. (pix/video width-height, etc)
The way I see it, the sfari browser, and the download manager are 2 different puppies, and it maybe that these googleites are so much into object oriented lunacy, that they consider passing username/password from one object to another a "security risk" (i.e. memory sniffable). With a probably only way to solve the issue being to integrate the browser and download manager (I have no clue why they have to call an external download manager to handle a file which is already in memory loaded by the browser, yet another lunacy).
However, the easiest would be to add basic auth functionality to the download manager, so it "re-asks" you for a username/pass if needed, and voilla, only needs to remember it after a reboot.
C'mon google, 4-5 years already wth !
fm...@gmail.com <fm...@gmail.com> #123
How is this labeled an enhancement? This is easily a medium priority bug.
ch...@gmail.com <ch...@gmail.com> #124
Same problem Nexus 10.
ch...@gmail.com <ch...@gmail.com> #125
It is without doubt a bug... the solution at the moment is to use Firefox which supports this fine. I'm amazed this has been known about since 2008!!
ma...@gmail.com <ma...@gmail.com> #126
F***ing unbelievable this hasn't been fixed in 5 f***ing years, and absolutely demential that it's still marked as an enhancement.
This is wrong behavior, hence a bug. And this prevents users to download things, hence it's HUGE.
Priority "medium" is another astonishing mistake.
This is wrong behavior, hence a bug. And this prevents users to download things, hence it's HUGE.
Priority "medium" is another astonishing mistake.
sr...@gmail.com <sr...@gmail.com> #127
I too experience this problem. Tested with Chrome on stock GSM Galaxy Nexus with JellyBean, also stock Nexus One tablet. It works on the Android browser, but not with Chrome.
I have a personal server at home running Ubuntu with Apache to easily transfer files onto my Android devices. It is password protected. Tried downloading apk, mp3, and zip files. Files containing text work, the rest failed. I also tried clearing cache on "Download Manager", "Downloads", "Chrome", and force quitting all three of those programs before trying again.
Same files download fine with the stock Android browser.
Apache log shows an unauthorized download attempt (401 error):
192.168.1.1 - - [19/Aug/2012:17:12:42 -0700] "GET /files/test.zip HTTP/1.1" 401 792 "-" "Mozilla/5.0 (Linux; Android 4.1.1; Galaxy Nexus Build/JRO03C) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19"
I have a personal server at home running Ubuntu with Apache to easily transfer files onto my Android devices. It is password protected. Tried downloading apk, mp3, and zip files. Files containing text work, the rest failed. I also tried clearing cache on "Download Manager", "Downloads", "Chrome", and force quitting all three of those programs before trying again.
Same files download fine with the stock Android browser.
Apache log shows an unauthorized download attempt (401 error):
192.168.1.1 - - [19/Aug/2012:17:12:42 -0700] "GET /files/test.zip HTTP/1.1" 401 792 "-" "Mozilla/5.0 (Linux; Android 4.1.1; Galaxy Nexus Build/JRO03C) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19"
r....@gmail.com <r....@gmail.com> #128
Srsly fix this please!
ma...@gmail.com <ma...@gmail.com> #129
I was going to echo that the problem occurs on my device as well. However, reading through this topic, I don't think it matters what my device is because clearly the device isn't the problem. Neither is DownloadManager. Neither is Android. If something has been broken for five years (on a function that has existed in other HTTP clients since a mid 1990's RFC), I would posit the problem is Google. As a whole. I regret my investment in a Google tablet if this is how Google handles simple functionality problems in their code. Perhaps they should stick to cataloging URLs. I will not be recommending Google devices.
ph...@gmail.com <ph...@gmail.com> #130
Still not fixed and still classified as "enhancement"? It's a bug! Just look at http://www.ietf.org/rfc/rfc1945.txt Page 48: "In spite of this, clients should implement the scheme in order to communicate with servers that use it."
Srsly, Google - fix it already! Please!
Srsly, Google - fix it already! Please!
ch...@gmail.com <ch...@gmail.com> #131
I'm suffering the same problem, please mark as bug or give some status update.
fa...@gmail.com <fa...@gmail.com> #132
Please fix this bug asap. Thx
vl...@gmail.com <vl...@gmail.com> #133
Please fix this!
hu...@gmail.com <hu...@gmail.com> #134
And just to add to this, not fixed in 4.2.2 either. Let's see if we can roll over to sixth years anniversary soon with this problem. :)
ru...@gmail.com <ru...@gmail.com> #135
Well, i went through this and read the only response from the Project member:
http://code.google.com/p/android/issues/detail?id=1353#c51
The sentence from the RFC
"The client MAY repeat the request with a suitable Authorization header field."
is out of context and has completely different meaning in RFC.
Moreover, the problem here is before getting the 401 response. Unauthorized response code is only consequence of previous bad behavior.
This is really sad and very unprofessional :( Same as the pure existence of this whole thread.
The sentence from the RFC
"The client MAY repeat the request with a suitable Authorization header field."
is out of context and has completely different meaning in RFC.
Moreover, the problem here is before getting the 401 response. Unauthorized response code is only consequence of previous bad behavior.
This is really sad and very unprofessional :( Same as the pure existence of this whole thread.
ma...@gmail.com <ma...@gmail.com> #136
Its human to make mistakes. It can happen that you forget things. But it is not okay that it takes 5years (and more) to add something that is so trivial but important at the same time.
ya...@gmail.com <ya...@gmail.com> #137
5 years for Medium Priority Issue !!?
so...@gmail.com <so...@gmail.com> #138
I do face similar issue but not 401 status code..but recieving 2 requests for same resource (after ~60% download, second request kicks in to server). I'm Glad 2 copies are not getting downloaded!! But, 2nd request, which i believe made by ADM, causes efficiency of my "download counter", imagine if, i'm delivering permium content and charging users based on download, because of such behaviour of "client", somebody have t pay the price, unless extra workarounds implemented to nullify effect of this BUG.
Android browser should integrate ADM and everybody will live in harmoy..!!
Please fix!!
Android browser should integrate ADM and everybody will live in harmoy..!!
Please fix!!
me...@gmail.com <me...@gmail.com> #139
No updates on a solution for this? Any alternatives in apache2 for basic auth that someone knows of?
cl...@gmail.com <cl...@gmail.com> #140
As Google does not seem to listen to this issue, we should make an effort to bring it to the different Android blogs, so more people get aware about Google's customer care. Decision makers need to know about this, it can be a complete show stopper for certain scenarios.
2s...@gmail.com <2s...@gmail.com> #141
YES YOU ARE ABS RIGHT IT IS SHOW STOPPER FOR US NOW, ITS BEEN MORE THAN A ONE WEEK NOW WE ARE STUCK WITH THIS BIZZARE PROBLEM.
GOOGLE MUST RESOLVE THIS FOR OVERALL BENEFIT AND POPULARITY OF ANDRIOD CUSTOMERS.
------------------------------------
We tried all the suggested resolutions on this page. Our aim is to access pdf files from our SharePoint Portal.
Opera Mobile Browser:Plugin content error.
Firefox Mobile Browser:No errors, Home page of the portal is partially rendered.
Does these browser support JSRender on Android.
GOOGLE MUST RESOLVE THIS FOR OVERALL BENEFIT AND POPULARITY OF ANDRIOD CUSTOMERS.
------------------------------------
We tried all the suggested resolutions on this page. Our aim is to access pdf files from our SharePoint Portal.
Opera Mobile Browser:Plugin content error.
Firefox Mobile Browser:No errors, Home page of the portal is partially rendered.
Does these browser support JSRender on Android.
co...@googlemail.com <co...@googlemail.com> #142
Progress!
Seems fixed by Intel guyshttps://01.org/android-ia/downloads/2013/android-4.2.2r1-ia1 (there is some problem with formatting on that link just now but it will likely be fixed soon)
Will it be accepted upstream tho'?? :)
Seems fixed by Intel guys
Will it be accepted upstream tho'?? :)
zl...@gmail.com <zl...@gmail.com> #143
I wonder if the Intel patch fixes Windows auth as well? My company has a password protected directory through IIS using Windows auth and none of our Android tablets can download anything within that directory successfully.
The workaround we're currently telling people is to use Firefox when downloading from our site. Ridiculous though, 5 years to get this fixed! Please mark as a bug and not an enhancement!
The workaround we're currently telling people is to use Firefox when downloading from our site. Ridiculous though, 5 years to get this fixed! Please mark as a bug and not an enhancement!
re...@gmail.com <re...@gmail.com> #144
Is there an Intel patch that fixes this issue on Jellybean? Samsung Galaxy Note 10.1. Corporate office runs nearly an entirely Google based system, and this "moderate" issue is annoying. Copying link address and pasting into Firefox browser is only current workaround.
ti...@gmail.com <ti...@gmail.com> #145
It seems to me that the Android Download Manager can't handle basic authentication at all. I have to use another download manager app, which will ask for the user information, to complete the download.
ni...@gmail.com <ni...@gmail.com> #146
This problem persists trough few years already I find people reports about this dating since 2009
ja...@gmail.com <ja...@gmail.com> #147
Cooooome on. How is this not fixed yet?
So much for using Android for B2B.
So much for using Android for B2B.
qi...@chromium.org <qi...@chromium.org> #148
just FYI, the latest Chrome Beta on android (version 28.0.1500.21) should have fixed all the download issues.
fo...@gmail.com <fo...@gmail.com> #149
I can confirm that chrome 28.0.1500.21 (currently beta) fixed it for me. Hallelujah! Took you long enough google >.<
jb...@android.com <jb...@android.com> #150
[Comment deleted]
jb...@android.com <jb...@android.com> #151
[Comment deleted]
jb...@android.com <jb...@android.com> #152
[Comment deleted]
Description
address. I use only HTTP Basic Authentication to control access to this
archive. Upon trying to download anything from this archive via the web,
using either the T-Mobile 3G network or Wi-Fi directly, the WebKit browser
would say "Download unsuccessful." As soon as I disabled HTTP Basic
Authentication, downloads worked fine.
So I'm able to access the site using HTTP Basic Authentication
successfully, at least for browsing purposes. But somehow, this
information isn't getting passed through whenever the agent goes to
download an actual file. This appears to be a definite bug.