77850 - data:audio/mp3;base64 doesn't download correctly

Status: VERIFIED FIXED

(Core :: Networking, defect, P1)

Description

[Hixie (not reading bugmail)]

STEPS TO REPRODUCE
   1. Visit http://hixie.ch/tests/adhoc/data/001.html
   2. Download the sound file that the link points to.
   3. Listen to it.

ACTUAL RESULTS
   The download results in a broken 4 character file instead of the 10002 byte
   audio stream that was expected.

EXPECTED RESULTS
   "The hats were my idea!"

Comment 1

[Hixie (not reading bugmail)]

Amazingly enough, the URL field for this bug also points to the same sound file.
So you can use that instead of my test file.

Comment 2

[neeti]

-->law

Comment 3

[Bill Law]

I need help from Networking on this one.

No matter how I try to process this data: url, I get only 4 bytes of data.  
This happens whether I click on the link (the data then arrives at 
nsExtAppHandler::OnDataAvailable), or, right-click on choose "save link as" 
(the data then arrives at nsStreamXferOp::OnDataAvailable).  In both cases, 
there's only 4 bytes of data.  This may be due to something in nsDataChannel, 
or it may be due to something funky happening to the URI along the way.

In the former case, it's a Networking problem.  In the latter, they're going to 
have to tell us how to avoid this (note that it happens in two separate code 
paths, so it must be kind of tricky).

I'm sending back to Neeti.  Can you look at nsDataChannel::AsychOpen and figure 
out why streamLen is always 4 for this URL, please?  Thanks.

Comment 4

[Christopher Blizzard (:blizzard)]

What's going on with this bug?

Comment 5

[neeti]

Bill: I applied the patch from bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=78876 locally to my tree. We now the 
get correct number of bytes (10002) in streamlen in 
nsDataChannel::AsynchOpen(..), instead of 4. 

However, we still have have problems downloading the file, when we use the "save 
this file to Disk" option in the Downloading dialog.

I am still keeping this bug open, instead of closing this one and opening a new 
bug, because this bug is about not downloading the file correctly and problem 
still exists even with the patch applied. Feel free to do otherwise.

Over to you to investigate this further..

Comment 6

[Bill Law]

OK, thanks.  I will apply that patch and figure out what's going wrong with the
download.

Comment 7

[Andreas M. "Clarence" Schneider]

*** Bug 81190 has been marked as a duplicate of this bug. ***

Comment 8

[benc]

mass move, v2.
qa to me.

Comment 9

[Paul Chen]

nav triage team:

marking nsbeta1+, p3, and mozilla0.9.3

Comment 10

[Viswanath Ramachandran]

-> alecf for investigation. it would be nice to reassess this bug and see if we 
can have for Netscape rtm. 

Comment 11

[Alec Flett]

well, data: isn't an officially supported schema, to the best of my
knowledge...but I'll take a look.

Comment 12

[Andreas M. "Clarence" Schneider]

<data:> is defined in RFC 2397. Status is "Proposed Standard".

Comment 13

[Alec Flett]

I'm pretty sure this is a uriloader or MIME thing. I just tried this on the
branch build, and nothing happens. I'm reassigning to mscott for now, but
staying on the CC in case I can figure out a good workaround.

Comment 14

[Scott MacGregor]

I don't believe this is a nsbranch quality bug. I wouldn't take it in a limbo
build. removing the nsbranch keyword. 

Comment 15

[Alec Flett]

I agree actually :)
this appearantly got the nsbranch keyword because the triage team just
misunderstood and thought it meant that no mp3 links worked at all.

Comment 16

[Scott MacGregor]

triaging.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Not all nsIURIs are nsIURLs

So..  The "URL" field of this bug is truncated to 255 chars and thus does not
work.  The base64 decoding fails, throws an error, this error is propagated up
to nsDocShell::LoadURI which throws it... and somewhere something ends up
ignoring the load failure (I think that notification of errors in loadURI is
disabled because of too many false positives or something....)

The URL at http://hixie.ch/tests/adhoc/data/001.htm works once this patch is
applied.

Comment 18

[Hixie (not reading bugmail)]

That should be http://hixie.ch/tests/adhoc/data/001.html

Comment 19

[Bill Law]

Comment on attachment 79725 [details] [diff] [review]
Not all nsIURIs are nsIURLs

r=law

Comment 20

[Boris Zbarsky [:bzbarsky]]

To me, since I have a fix in any case...

Comment 21

[Darin Fisher]

Comment on attachment 79725 [details] [diff] [review]
Not all nsIURIs are nsIURLs

sr=darin, though i'm not sure how fname and mSourcePath will be used.  does it
make sense for the path of a data URI to be used like this?

Comment 22

[Boris Zbarsky [:bzbarsky]]

They're used to say where the data is coming from (and cropped in the process if
needed).

Fixed on trunk.

Comment 23

[Jimmy Lee]

Build: 2002-10-22-08-trunk

File is downloaded as 10002 byte file.  mp3 files plays seemingly just fine.

Marking Verified!

Comment 24

[benc]

fixed URL so it will work.