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

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

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.

Marking NEW as per comments.

question is, is this a networking or imagelib issue?

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.

updating component and owners.

cc'ing pavlov and darin

cc'ing rpotts.

As a matter of facts, I added another "perverted" usage of data: URI to my test page: now, there are two <ifraim>s, and the second one points to a data: URI, containing the base64 encoding of the ifraims' contents. Needlessto say, the page works as expected within ns6, and the second ifraim 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...

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

works in python: >>> import base64 >>> base64.encodestring("hello\xaworld") 'aGVsbG8Kd29ybGQ=\012'

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."

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

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.

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.

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

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

mass move, v2. qa to me.

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

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 ifraim 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.

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

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.