Bug 104239 - HTTP Accept Header should indicate SVG support
Summary: HTTP Accept Header should indicate SVG support
Status: RESOLVED NOT A BUG
Alias: None
Product: kio
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-19 22:25 UTC by Steffen Weber
Modified: 2018-04-25 18:37 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steffen Weber 2005-04-19 22:25:49 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
OS:                Linux

Konqueror supports SVG images, but does not tell the server that this support is present. This should be done by adding "image/svg+xml" to the "Accept" header which is sent with each request.

The Mozilla developers seem to have already agrred on adding this header, although noone has done it yet: https://bugzilla.mozilla.org/show_bug.cgi?id=240493
Comment 1 Thiago Macieira 2005-04-21 22:20:01 UTC
Reassigning to main kio:

kio/kio/http_slave_defaults.h:#define DEFAULT_ACCEPT_HEADER           "text/html, image/jpeg, image/png, text/*, image/*, */*"
Comment 2 David Faure 2005-04-24 02:46:02 UTC
Doesn't "image/*" match image/svg+xml?
Does this report mean that HTTP servers ignore wildcards?

The tricky bit here is that image/svg+xml is only supported when KSVG is installed (i.e. kdegraphics). But well, we can still add it by default, I guess. Users should have kdegraphics :)
Comment 3 Steffen Weber 2005-04-24 11:12:14 UTC
> Doesn't "image/*" match image/svg+xml?
> Does this report mean that HTTP servers ignore wildcards?
So all browsers support SVG? Interesting. ;-)

> The tricky bit here is that image/svg+xml is only supported when KSVG is installed (i.e. kdegraphics). But well, we can still add it by default, I guess. Users should have kdegraphics :)
At first I assumed that, too, and delivered SVG by default when the User-Agent matched "Konqueror/3.4". But a friend using Debian did not have KSVG, although he had Konqueror 3.4. :-(
Comment 4 David Faure 2005-04-25 11:16:42 UTC
On Sunday 24 April 2005 11:12, Steffen Weber wrote:
> > Doesn't "image/*" match image/svg+xml?
> > Does this report mean that HTTP servers ignore wildcards?
> So all browsers support SVG? Interesting. ;-)

?? This isn't about all browsers, it's about Konqueror.
It claims to support all types of images, yes :)

> > The tricky bit here is that image/svg+xml is only supported when KSVG is installed (i.e. kdegraphics). But well, we can still add it by default, I guess. Users should have kdegraphics :)
> At first I assumed that, too, and delivered SVG by default when the User-Agent matched "Konqueror/3.4". But a friend using Debian did not have KSVG, although he had Konqueror 3.4. :-(

So this report is indeed about adding image/svg to the HTTP accept header *only* when ksvg is available.... :(
KIO doesn't have support for this kind of thing at the moment.
Comment 5 Steffen Weber 2005-04-25 12:04:44 UTC
At least I think it would be the correct way to implement this. I´m not sure if adding image/svg+xml to the Accept header reagrdless of KSVG´s availability would help Konqueror more than it could hurt, because some servers might decide to rely on SVG support and not provide a fallback PNG.

I would say better try to implement this correctly, unless you think that it still won´t be possible to detect KSVG from inside Konqueror in a few years.
Comment 6 Dawit Alemayehu 2011-05-25 20:29:19 UTC
This is not a KIO issue. By default KIO is configured to send a set of default accept header types that is hard coded. However, kio_http allows this to be overridden through the KIO meta-data system by using the "accept" meta-data. As such, it is up to each client (read: rendering engine) to override or augment the default setting.

As far as the server is concerned, if the client says it supports image/*, then it should treat it as such regardless whether or not the client is able to render that image or not. This should probably be closed as WONT FIX...