8649 - data: URLs (RFC2397) not working

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Braden]

"data" URLs (per RFC2397) do not appear to be working. There should be two mandrill images displayed on this page. The first is from a PNG file accessed with a conventional URL. The second is an encoded PNG file placed inline in the HTML file in a "data" URL.

Comment 1

[leger]

elig...I think this is a dup of an issue you and pnunn already..yes?

Comment 2

[Eli Goldberg]

This may be a subset of 2110, "URI scheme parsing, extensibility broken/missing".

Gagan? Pam? Braden?

Thanks!

Comment 3

[pnunn]

Gagan:
I'm not getting a call to IL_GetImage().
It seems to stall out in NetlibMainLoop().
Reassigning to you, knowing that this will
probably be fixed in Necko landing.

-pn

Comment 4

[Braden]

While I don't know the exact scope of ImageLib, data URLs can be used for more
than just images. They should work anywhere that takes a URL--plug-in data,
linked resources (LINK, A), etc.

I do not think this is a dupe of 2110. That bug deals with the protocol
extensibility mechanism, and this deals with support for a specific protocol.

Comment 5

[Gagan]

Past necko landing...

Comment 6

[Gagan]

This should probably be done as a data: protocol handler which would internally
invoke the content convertor to appropriately give the correct image type
(binary) stream from the specified URL. Marking it for later. Cc'ing warren for
his comments.

Comment 7

[Warren Harris]

Yes, you're right. A data: protocol handler is what we need.

Comment 8

[Judson Valeski]

I'm done with this protocol. I'm just waiting for a response from gagan
regarding some url parsing stuff and I'll check it in.

Comment 9

[Gagan]

Jud asked for it... here you go! :)

Comment 10

[Judson Valeski]

I checked in my changes. Windows works now. Andreas is verifying a unix build,
then unix will be online. Mac still needs the prj.

Jud

Comment 11

[Braden]

Man, this is *sweet*.

I'm gonna go compile my whole Web site into one big file.

No, not really.

Comment 12

[Judson Valeski]

linux is up and running

Comment 13

[gordon]

Mac projects created and in the build.  I see the mandrills on the Mac.

Comment 14

[Eli Goldberg]

This appears to be fixed using the 1999092908 Mac OS build. Two mandrill images
appear. Eli feels nostalgic, remembering the image from a 1985 Amiga 1000 demo.
;)

braden@endofframe, would you like to please double-check this? (I'm not familiar
with RFC2397, and have only confirmed that your test case works.)

Thanks!

Comment 15

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 16

[David A. Madore]

*** Bug 31486 has been marked as a duplicate of this bug. ***

Comment 17

[David A. Madore]

I can't get this feature working on Linux 2000030709 build.  Is this broken or
am I just careless?

Comment 18

[Warren Harris]

david.madore: I don't understand -- this is a mac bug, but you put a linux 
comment here. Also this bug is closed. Has this problem resurfaced?

Comment 19

[benc]

Mac/NT? Sorry, had to fix that. per #10, this bug is the allplats implementation
bug.

Comment 20

[dotnetCarpenter]

I've created a similar bug for "long data in Data-URLs" #813139, that I think this should depend on. Thus this bug should be re-opened.
https://bugzilla.mozilla.org/show_bug.cgi?id=813139

Comment 21

[Masatoshi Kimura [:emk]]

It's completely unrelated. Blindly searching for "data URL" couldn't find a similar bug.

Comment 22

[dotnetCarpenter]

@Masatoshi: I don't follow your logic. How would a search for "data URL" prove that this is unrelated?  This bug states that RFC2397 is not working on mac. My bug report states that RFC2397 is not working on mac in certain cases... Seems similar to me.