Last Comment Bug 73026 - data: 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
Status: VERIFIED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla1.0
Assigned To: neeti
: benc
: Patrick McManus [:mcmanus]
Mentors:
http://sancho.ccd.uniroma2.it/%7elore...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-22 09:35 PST by Lorenzo
Modified: 2002-09-06 18:01 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Lorenzo 2001-03-22 09:35:17 PST
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 Jacob Kjome 2001-03-22 20:59:19 PST
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.

Jake
Comment 2 Richard Brodie 2001-03-23 05:27:40 PST
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 Keyser Sose 2001-03-25 15:15:20 PST
Marking NEW as per comments.
Comment 4 Doron Rosenberg (IBM) 2001-03-29 06:25:31 PST
question is, is this a networking or imagelib issue?
Comment 5 Lorenzo 2001-03-29 06:50:32 PST
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
URI.
Comment 6 Asa Dotzler [:asa] 2001-03-29 11:01:33 PST
updating component and owners.
Comment 7 neeti 2001-03-29 11:22:38 PST
cc'ing pavlov and darin
Comment 8 Darin Fisher 2001-03-29 12:15:49 PST
cc'ing rpotts.
Comment 9 Lorenzo 2001-03-30 04:35:12 PST
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 rpotts (gone) 2001-03-30 14:43:47 PST
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 Darin Fisher 2001-03-30 16:08:14 PST
works in python:

>>> import base64
>>> base64.encodestring("hello\xaworld")
'aGVsbG8Kd29ybGQ=\012'
Comment 12 Lorenzo 2001-03-31 07:58:02 PST
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 white.space, 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 Stuart Parmenter 2001-03-31 14:27:08 PST
the url in this bug doesn't seem to be up
Comment 14 Lorenzo 2001-04-01 07:28:07 PDT
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.
Comment 15 Stuart Parmenter 2001-04-27 02:59:54 PDT
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.
Comment 16 Lorenzo 2001-04-27 11:40:55 PDT
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 Jacob Kjome 2001-05-16 15:47:28 PDT
Note that this bug is pretty much fixed by bug 78876 ( I also noted this in bug 
76312 )

However, as far as http://sancho.ccd.uniroma2.it/%7elorenzo/tst.html 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!

jake
Comment 18 benc 2001-05-23 12:34:25 PDT
mass move, v2.
qa to me.
Comment 19 Jacob Kjome 2001-07-10 11:30:45 PDT
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?

jake
Comment 20 Lorenzo 2001-07-10 12:11:01 PDT
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 Jacob Kjome 2001-07-10 12:50:38 PDT
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.

jake
Comment 22 Jeremy M. Dolan 2002-07-10 11:46:31 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.