After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 528862 - data URI support
data URI support
Status: RESOLVED DUPLICATE of bug 557777
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other All
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2008-04-19 06:57 UTC by alp
Modified: 2010-08-16 02:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description alp 2008-04-19 06:57:28 UTC
Support for parsing data URIs and returning their content-type through the standard API and actual content through the same callback path as HTTP URIs would be handy. We implement this in WebKit directly right now but our code isn't fully tested (the RFC sucks so you have to test against the examples in the WebKit and Mozilla test suites and live content on the web) and we'd rather share this feature with the rest of the platform.

The new base64 decoder functions in GLib are helpful in implementing this.
Comment 1 Dan Winship 2008-04-20 16:42:46 UTC
As discussed in bug 526755, I don't think that having SoupMessage and SoupSession operate on URIs other than http: and https: makes sense, because the idea of other URI types behaving in a pseudo-http-like way is a web-browser-level API, not an HTTP-library-level API.

However, there might be other apps besides web browsers that want to parse data: URIs, so I may still end up adding API for it (though not via SoupMessage/SoupSession)...
Comment 2 Dan Winship 2010-08-16 02:22:54 UTC
this will (eventually) be handled as part of the uri-loader stuff

*** This bug has been marked as a duplicate of bug 557777 ***