|
Posted by Sander Tekelenburg on May 20, 2006, 8:15 am
Please log in for more thread options
> Hey, I have a Safari-related question.
Not really, this is a Web authoring question. I think
<news:comp.infosystems.www.authoring.html> is probably the most on topic
group for that. Crossposted and follow-ups set.
> We're doing this site: http://www.bossesfromhell.com (not a spam, just
> so you can see what I'm talking about).
>
> Basically I'm attaching an XSLT-stylesheet to some XML, which happens to
> be in RSS format. Now, this works fine in Safari 1.3 - but when it's
> viewed in Safari 2.0.3, the XSLT goes away and safari displays it as an
> RSS feed.
>
> Is there any way that anyone can think of to prevent this?
Erm, not serve RSS when you don't mean to? ;)
"Be conservative in what you send and liberal in what you except" and all
that... In other words, serve HTML, not XML. Aside from the problem you
ran into, not every user-agent speaks XML. Serving HTML 4.01 your
content will be accessible to more recipients.
Now I can imagine there *might* be the odd special situation where it
*might* be useful to serve XML, but on the *Web* you'd better make damn
sure you're 100% certain (which isn't easy) the receiving user-agent can
handle it. When you're not, serve HTML.
For example, when my browser connects to your server, it tells it this:
Accept: image/png;q=0.7, image/jpeg;q=0.6, image/pjpeg;q=0.6,
image/gif;q=0.5, image/x-xbitmap;q=0.4, image/xbm;q=0.4,
text/html;q=0.9, application/xhtml+xml;q=0.7, text/plain;q=0.6, */*;q=0.1
I don't see it claim it can handle text/xml, yet your server responds
with this:
Content-Type: text/xml
So the user-agent explicitly tells your server what it can handle, and
then your server feeds it something else after all. (This user-agent
still manages to present it as an RSS feed, just like Safari, but that's
clearly not your aim.)
[Note follow-ups]
--
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
Mac user: "Macs only have 40 viruses, tops!"
PC user: "SEE! Not even the virus writers support Macs!"
|
|
Posted by Steve Pugh on May 20, 2006, 8:27 am
Please log in for more thread options
>
>> We're doing this site: http://www.bossesfromhell.com (not a spam, just
>> so you can see what I'm talking about).
>>
>> Basically I'm attaching an XSLT-stylesheet to some XML, which happens to
>> be in RSS format. Now, this works fine in Safari 1.3 - but when it's
>> viewed in Safari 2.0.3, the XSLT goes away and safari displays it as an
>> RSS feed.
>>
>> Is there any way that anyone can think of to prevent this?
>
>Erm, not serve RSS when you don't mean to? ;)
Yep, good advice.
The betas of IE7 and Opera 9 also act exactly as Safari did. Of my
browsers only Firefox didn't think it was a feed.
Within the broad range of screwed up content and content-types on the
WWW this looks to a browser very much like an RSS feed so it should
come as no surprise that browsers treat it as an RSS feed.
>"Be conservative in what you send and liberal in what you except" and all
pedant: accept not except. Being liberal in what you except is very
close to the opposite of what you meant. ;-)
>that... In other words, serve HTML, not XML. Aside from the problem you
>ran into, not every user-agent speaks XML. Serving HTML 4.01 your
>content will be accessible to more recipients.
>
>Now I can imagine there *might* be the odd special situation where it
>*might* be useful to serve XML, but on the *Web* you'd better make damn
>sure you're 100% certain (which isn't easy) the receiving user-agent can
>handle it. When you're not, serve HTML.
>
>For example, when my browser connects to your server, it tells it this:
>
>Accept: image/png;q=0.7, image/jpeg;q=0.6, image/pjpeg;q=0.6,
>image/gif;q=0.5, image/x-xbitmap;q=0.4, image/xbm;q=0.4,
>text/html;q=0.9, application/xhtml+xml;q=0.7, text/plain;q=0.6, */*;q=0.1
>
>I don't see it claim it can handle text/xml,
Except that it does: */* includes text/xml as well as everything else.
>yet your server responds with this:
>
>Content-Type: text/xml
>
>So the user-agent explicitly tells your server what it can handle, and
>then your server feeds it something else after all.
If the document only exists as text/xml then the fact that your UA has
included */* even with a low q value means that it is claiming that it
will accept it if nothing more suitable is on offer.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
|
|
Posted by Alan J. Flavell on May 20, 2006, 8:54 am
Please log in for more thread options
On Sat, 20 May 2006, Steve Pugh wrote:
> If the document only exists as text/xml then the fact that your UA
> has included */* even with a low q value means that it is claiming
> that it will accept it if nothing more suitable is on offer.
Yes. When directly retrieving some resource, it *might* (on the
server side you don't know, and aren't really supposed to know) just
be the client's way of saying OK, if you haven't got a content type
that I know I can handle, then at least I can offer to download some
unknown content-type and leave the user to work out what to do with
it. Or the user might get the option to tell the browser which
"helper" application to use for this new content-type, if it doesn't
already know it.
What seems to me less excusable is where a browser retrieves an
embedded object such as <img src=...> , using an "Accept:" header
which includes */*, when in fact it won't be able to do a damned thing
if the resource doesn't turn out to be the right sort of thing that it
was expecting.
|
|
Posted by Sander Tekelenburg on May 20, 2006, 10:31 pm
Please log in for more thread options
[...]
> What seems to me less excusable is where a browser retrieves an
> embedded object such as <img src=...> , using an "Accept:" header
> which includes */*, when in fact it won't be able to do a damned thing
> if the resource doesn't turn out to be the right sort of thing that it
> was expecting.
Yes, interesting point. FWIW though, I haven't found a user-agent yet
that does not claim it can't eat anything. All that I tried list */* as
a last resort. Several (Safari, links, Mozilla, MacIE) even simply
*only* say "Accept: */*", no more.
I haven't yet tried if any user-agents send a different Accept header
when requesting such things as embedded images, but given the above I'd
be surprised.
--
Sander Tekelenburg, <http://www.euronet.nl/%7Etekelenb/>
|
|
Posted by Alan J. Flavell on May 21, 2006, 7:15 am
Please log in for more thread options
On Sun, 21 May 2006, Sander Tekelenburg wrote:
> Yes, interesting point. FWIW though, I haven't found a user-agent
> yet that does not claim it can't eat anything. All that I tried list
> */* as a last resort.
For a direct retrieval, it makes sense. But for specialised resources
such as stylesheets, javascript, images etc. it's nonsense. If it
then retrieves a content-type that it doesn't understand, security
considerations (rfc2616) forbid processing the content, and those
browsers which disregard this mandate are doing nobody a favour.
> Several (Safari, links, Mozilla, MacIE) even simply
> *only* say "Accept: */*", no more.
I'm not sure where you saw that...? For direct retrieval with
Mozilla and friends, I get:
HTTP_ACCEPT =
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_CHARSET = ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_ENCODING = gzip,deflate
...
HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1
and
HTTP_ACCEPT =
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_CHARSET = ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_ENCODING = gzip,deflate
...
HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.12) Gecko/20050915
(Win) MSIE however has a silly habit of sending a misleading set of
Accept: parameters on initial retrieval (which do NOT include explicit
mention of text/html), and then sending "Accept: */*" on reload. So a
server which is negotiating content could very well, and quite
correctly according to protocol, decide to send image/gif on the
initial request, and something else (let's say application/xml, for
example) on reload of the same URL.
MSIE's initial Accept header depends on which Office products one has
or hasn't installed, but mine looks like this:
HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
So, as I say, negotiated content would prefer image/gif, or
Powerpoint, etc., but would only get sent HTML under the provisions of
*/*, if nothing else was available. Even if I set the source quality
of the MS-Word version to be 0.01, they'd get it in preference to the
qs=1.0 HTML variant. Crazy (or deliberate sabotage of web protocols,
who can tell what they really intend?).
> I haven't yet tried if any user-agents send a different Accept
> header when requesting such things as embedded images, but given the
> above I'd be surprised.
Ethereal does a reasonable job of logging such things for all kinds of
requested content, although I hadn't actually researched this topic
recently - but I've just taken a look at the headers which are used
for retrieving resources which are referenced from an HTML page.
This was just a quick test - there may be errors - anyone intending to
use this information for anything is urged to do their own tests.
Mozilla/Seamonkey seem to make requests like this...
CSS: text/css, */*;q=0.1
JS: */*
Image: image/png, */*;q=0.5
MSIE6, boringly, like this:
CSS: */*
JS: */*
Image: */*
Opera 9 beta - seems to retrieve *everything* using the same
Accept header:
HTTP_ACCEPT = application/xhtml+voice+xml;version=1.2,
application/x-xhtml+voice+xml;version=1.2, text/html,
application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg,
image/gif, image/x-xbitmap, */*;q=0.1
regards
|
| Similar Threads | Posted | | Safari users, help please | September 12, 2005, 7:09 am |
| Interesting Safari Problem | December 10, 2004, 8:30 am |
| Works in IE, Firefox but not on Safari | September 8, 2006, 8:29 pm |
| Safari issue with self.close | February 28, 2007, 12:51 pm |
| pages not displaying properly in safari | March 18, 2006, 5:18 pm |
| Apple Safari: select box behaviour | January 8, 2008, 10:21 am |
| Safari, image maps, and links | May 12, 2008, 3:58 pm |
| Looking for solution for iPhone/Mobile Safari | June 19, 2008, 9:44 pm |
| safari nested tables height percentual bug? | September 11, 2004, 1:47 am |
| simple safari test cases: puzzling | September 22, 2004, 1:45 pm |
|
XML Sitemap