data: gif image embedded as "data:image/gif;base64" URI doesn't show

VERIFIED FIXED in mozilla1.0



18 years ago
17 years ago


(Reporter: lorenzo, Assigned: neeti)


({regression, testcase})


Firefox Tracking Flags

(Not tracked)





18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.19pre11 i686; en-US; 0.8) Gecko/20010306
BuildID:    2001030612

Inside the named test page there are two instances of the image described in
rfc2397. While in the first one, the base64 representation doesn't contain
newlines, in the second one, there are newlines in between string-strides.
As a matter of facts, netscape 4.x does show the images well. What is sad is
this very same non-implementation affects M$ explorer!

Reproducible: Always
Steps to Reproduce:
Open the named url

Comment 1

18 years ago
I've been looking for something like this to be supported.  It would make
displaying images out of a database a bit easier....not that I'd want to do it
all that often, but it would be nice to know I could do it.


Comment 2

18 years ago
Confirming  win32/2001031904. 
This bug seems to come and go a bit: perhaps a candidate for a testcase?

According to bug 35439 it was fixed around a year ago. It also works OK in N6, 
so I guess it's a regression as well as a N4 compatibility problem.

Comment 3

18 years ago
Marking NEW as per comments.
Ever confirmed: true
Keywords: regression
question is, is this a networking or imagelib issue?

Comment 5

18 years ago
I would call this a networking issue, since "data:*/*;<xfer-enc>" is a general
use URI, which only "happens" to be mostly used inside <img> tags. I understand
this is from an abstract view-point, since I never ever tried to understand 
mozilla inner working.

Just to clarify: I would expect mozilla to handle the data: URI in the test page
just like NS 4.76 and 6.0 on windows do: displaying the image encoded within the

Comment 6

18 years ago
updating component and owners.
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → tever

Comment 7

18 years ago
cc'ing pavlov and darin

Comment 8

18 years ago
cc'ing rpotts.

Comment 9

18 years ago
As a matter of facts, I added another "perverted" usage of data: URI to my
test page: now, there are two <iframe>s, and the second one points to a data:
URI, containing the base64 encoding of the iframes' contents.

Needlessto say, the page works as expected within ns6, and the second iframe
is empty within M6.

Now, a side question: how do one file a bug against MS explorer , which doesn't
support data: URIs? I feel interop is really important, and therefore I would
like for them to support it...

Comment 10

18 years ago
I took a quick look at what's happening and it appears that PL_Base64Decode(...) 
is failing because it is encountering the character '0x0a' - which does not 
appear to be a valid char...

This causes the data:// channel to fail during its creation...

Is anyone a base64 guru?

-- rick

Comment 11

18 years ago
works in python:

>>> import base64
>>> base64.encodestring("hello\xaworld")

Comment 12

18 years ago
No base64 guru here, but maybe a small quote from rfc2045 could help...
at [page 24], after "Table 1: The Base64 Alphabet", there is a relevant
paragraph, which I'm quoting here (starred part is meant to be read
as underlined by myself):

RFC> The encoded output stream must be represented in lines of no more
RFC> than 76 characters each.  *All line breaks or other characters not
RFC> found in Table 1 must be ignored by decoding software*.  In base64
RFC> data, characters *other than* those in Table 1, *line breaks*, and *other
RFC> white space* probably indicate a transmission error, about which a
RFC> warning message or even a message rejection might be appropriate
RFC> under some circumstances.

Therefore, I think that "failing because it is encountering the character
'0x0a'" is not in line with rfc mandated behaviour, since 0x0a is a line-break!
IMHO, the decoding should continue after white-space and line break (say: 0x20
and \t surely are whsp, \r,\n,\r\n are line-breaks).

All of this doesn't explain why the first image fails to show, since the char
stream is ininterrupted there.

Last thing: maybe the base64 decoding failure for non-{white-space,line-break}
coould be signaled?

After a shallow-reading of RFCs grep-relevant to, I think the rule
we should follow is something along the lines of: "define white-space in this
context as being anything in the {\x20,\t,\r,\n} set, and collapse all white
space to nothing while doing the base64 decoding."

Comment 13

18 years ago
the url in this bug doesn't seem to be up

Comment 14

18 years ago
Just tried the URL in question, and it works, both if put textually in the
"location" box of my browser, and if i try and click on the "URL" link in this
page. Please try again, maybe there have been transient routing problems to
our network. I don't see anything strange in apache's logs, and the server is up
since March, 25.


18 years ago
Target Milestone: --- → mozilla1.0

Comment 15

18 years ago
bug 76312 is another problem of data: urls of images don't currently display,
however, this still seems to be a bug in the data: protocol handler.
Depends on: 76312

Comment 16

18 years ago
I'm sure it is a data: protocol handler problem, since, as I noted earlier
in the test page I put an <iframe src="data:text/html;base64...> tag whose 
contents are correctly rendered by ns6, and ignored by mozilla.

Comment 17

18 years ago
Note that this bug is pretty much fixed by bug 78876 ( I also noted this in bug 
76312 )

However, as far as loading 
correctly (without crashing, that is), I reported another bug about 
data:text/html not working if there is even one empty space in the base64 URI.  
See that here: bug 81185

Getting close!


Comment 18

18 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 19

18 years ago
I think this is bug is fully fixed.  The last thing that I mentioned that 
wasn't working correctly was "data:text/html not working if there is even one 
empty space in the base64 URI".  This was fixed in bug 81185.

Should this now be marked fixed or WFM and closed?


Comment 20

18 years ago
I'm unable to test with latest builds, therefore I'm not in a position todeclare the bug fixed myself. I'm running 0.9.1 now, and both the imagesshow as intended, but the 2nd iframe contents do not. Nonetheless, since I'munable to test with anything >=0.9.2, I wouldn't object to a status-change to"fixed", if you can confirm the test page loads completely.

Comment 21

18 years ago
Well, the whole page loads with build 2001071009 on Win2k (SP2).

Fix is attached to bug 81185 and has been checked in (at least on the trunk)

I'm marking this fixed.  Someone else can verify it fixed after that.

Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
wow... never knew about data: url thing... neat, and..weird and annoying. V
fixed, linux CVS. Now don't ever frigin use this feature you nuts.


17 years ago
No longer depends on: 76312
Keywords: testcase
Summary: gif image embedded as "data:image/gif;base64" URI doesn't show → data: gif image embedded as "data:image/gif;base64" URI doesn't show
You need to log in before you can comment on or make changes to this bug.