813139 - Long "data" in data-URLs is not working

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[dotnetCarpenter]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121113065533

Steps to reproduce:

I've created a test case that illustrates the issue. Go to https://c9.io/dotnetcarpenter/mireia/workspace/bugz/data-url.html
I've created the base64 encoding using nodejs and copied them into a static HTML file as src to images. The page was tested on Mac 10.7.5 and Windows 8 preview.


Actual results:

The small gif (1) appears to be working across the board, while big (2,3) and huge (4) data in data-URLs only works in Safari and Opera.


Expected results:

According to rfc2397 the effect is unknown but since other browser vendors (Apple and Opera) has implemented this, I think this should be a viable technology to use.

Citation from frc2307:
   The effect of using long "data" URLs in applications is currently
   unknown; some software packages may exhibit unreasonable behavior
   when confronted with data that exceeds its allocated buffer size.

A copy of the page (at least the images) should be placed in Mozilla data: URL tests. https://bug390837.bugzilla.mozilla.org/attachment.cgi?id=275148

Comment 1

[Masatoshi Kimura [:emk]]

Attachment: Working example

Comment 2

[Masatoshi Kimura [:emk]]

It's just your data URLs are broken. Opera and Safari are too lenient.

Comment 3

[dotnetCarpenter]

@Masatoshi how did you find out where the data URLs where broken and how did you fix it? I'm very interested in solving this. I initial thought that this was a Firefox/Chrome issue as they are the only browsers that doesn't display the original data urls. But as your example has showed me, it's the data url itself that is broken, I'm learning towards a nodejs bug. Can you advise please?

Comment 4

[dotnetCarpenter]

Further investigation with nodejs tells me that this is indeed a nodejs related issue. I support the resolution but am still interested in how you found and fix the breakage point in the data-URL.

If it's not too much to ask, could you supply some hints to how you went about discovering this?

Thanks, Jon

Comment 5

[Masatoshi Kimura [:emk]]

The "=" character can only occur at the tail of a base64-encoded string. You sample contained "=" at the middle of the string. That's incorrect.
If node.js api has a method something like flush(), you shouldn't call it until you convert all the data.

Comment 6

[dotnetCarpenter]

Thanks Masatoshi!

It's an issue with using node.js buffer and pipe feature. Which enables streaming of content to the browser in chunked Transfer-Encoding so the server doesn't have to load the entire image into memory. Apparently it also append "==" chars to each chunk of data. I'll have to dig a little and ask around the nodejs IRC for fix/wont-fix status but your answer gave me something to work with. Thanks.