Closed Bug 73026 Opened 20 years ago Closed 20 years ago

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

Categories

(Core :: Networking, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: lorenzo, Assigned: neeti)

References

()

Details

(Keywords: regression, testcase)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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.
Assignee: asa → neeti
Component: Browser-General → Networking
QA Contact: doronr → tever
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 <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...
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.
Target Milestone: --- → mozilla1.0
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
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.
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.
QA Contact: tever → benc
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 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.
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
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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.