Closed Bug 290876 Opened 20 years ago Closed 20 years ago

Accept header should indicate SVG support

Categories

(Core :: SVG, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 240493

People

(Reporter: steffen.weber, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050416 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050416 Firefox/1.0+

It should be possible to detect SVG enabled builds of Mozilla and Firefox in
some way, for example by adding image/svg+xml to the Accept header.

Currently, if you embed an SVG file in a website and view it in Firefox 1.0
there always pops up this yellow infobar which unsuccessfully tries to download
a suitable plugin. This also happens when you add an alternative image tag
inside the object tag. In conclusion there is no user-friendly way of
integrating SVG files on your website when you can provide an alternative png
file and do not want to annoy your users with this infobar.

If it would be possible for the server to only send the object tag when there
really is support for SVG this issue could be avoided.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.steffenweber.net/gecko-svg-notice/test.html
Actual Results:  
Firefox displays a yellow infobar because the website contains a reference to a
SVG file.

Expected Results:  
Firefox should tell the server if SVG support is enabled in order for the server
to decide whether the oject tag or just the image tag should be sent.
Searching for "Accept SVG" would have turned this bug up. Marking duplicate.

*** This bug has been marked as a duplicate of 240493 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
(In reply to comment #0)
> Currently, if you embed an SVG file in a website and view it in Firefox 1.0
> there always pops up this yellow infobar which unsuccessfully tries to download
> a suitable plugin. 

You're using type='text/svg+xml' on your <object> tag, and you're sending
'Content-Type: image/svg-xml' for your SVG file. Neither of these is correct.
You should be using image/svg+xml for both. Fix that, and you'll get rid of the
infobar. See

  http://jwatt.org/svg/authoring/#server-configuration

For some more info on configuring your server. The issue you raise about the
Accept header is a bug as Anne notes, but it's not causing the problem you
describe. (Kind of ironic that you're HTTP headers are wrong too. ;-)
First of all thanks for the quick replies and a big sorry for having created a
duplicate, I could have sworn that I searched for "svg accept". :-(

To the topic: Sounds like a bad excuse, but both mime type errors have only been
present in the given example. ;-) I´ve intoduced the "text/svg+xml" error while
creating the example and I did not know that the steffenweber.net server was not
configured correctly.

Both issues are now corrected, but contrary to what you (Jonathan) have said I
still get the yellow infobar if the Firefox build is not SVG enabled.
(In reply to comment #3)
> Both issues are now corrected, but contrary to what you (Jonathan) have said I
> still get the yellow infobar if the Firefox build is not SVG enabled.

Well of course, but I assumed (rather reasonably I think) that we were talking
specifically about SVG enabled builds. We're hardly going to send image/svg+xml
in the Accept header for non-SVG enabled builds. If the build isn't SVG enabled,
of course it's going to ask you if you want to install a plug-in for what is to
it an unsupported content type.
In comment #2 you quote me talking about "Firefox 1.0" and say that I could get
rid of this yellow infobar by correcting mime types. I think the
misunderstanding is that I´ve meant "Firefox 1.0 _without_ SVG", but my wording
was not very precise, to say the least. Sorry for the confusion, I think I´m
done now. ;-)
Ah, hehe. Okay, I see what you mean. As long as we're all clear on how things
work now. :-)
You need to log in before you can comment on or make changes to this bug.