Re: Content negotiation - ICS Calendar files
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 04.03.2006 um 03:25 schrieb Felipe Augusto van de Wiel (faw):
That's strange, accessing the above link via Mozilla and
Mozilla Firefox (both from etch) show me the HTML. I tried using
www.nl, www.us, www.br, www.de and just www. All worked fine for
me.
That is because Firefox and Mozilla prefer text/HTML over ICS. The
browser I used, where I can see the request, doen't negotiate such a
preference. So the server decides.
Here is what Omniweb sends:
GET /debian/dwww/events/2006/0513-debianday HTTP/1.1|Accept:image/
gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, image/tiff,
multipart/x-mixed-replace, */*;q=0.1
[..]
Camino sends:
GET /debian/dwww/events/2006/0309-cebit HTTP/1.1|Accept:text/
xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,image/png,*/*;q=0.5
As you might see, Camino has page preferences, while Omniweb has not.
Omniweb cares only about images and leaves it to the server to
decide, what kind of pages to deliver.
So Omniweb sometimes gets and displays plain text insted of html from
some servers, which is not a problem at all and wicht does not happen
for Debian. But getting an ICS causes a download for either Safari or
Omniweb and I cannot correct the URL in the URL field.
Okay, it is a bug in the browsers, too, that I cannot change that (as
far as I know). But _no_ web server with normal web pages should
prefer delivering ICS calendar files instead of HTML pages.
But seems, I can reproduce the behaviour on one server.
If I comment out the line
/etc/apache/mime.types:text/
calendar ics icz
it works fine.
if I reorder the text/html and text/calendar lines nothing chages
(wrong behaviour)
If I rename the text/calendar entry to something line text/aaa I get
the html page
If I change the calendar line to get other file extensions I get the
files with those extensions.
So it seems to be an Apache bug. It prefers calendar instead of html
internally, maybe out of the alphabetically order. Something must
tell Apache that an ics file has a higher media level.
If I follow the order at http://httpd.apache.org/docs/1.3/content-
negotiation.html it does not get to 8. (file size) as even a faked
ics file larger than the html page is delivered with preference.
Using var files (Type-map) instead of MultiViews the problem could be
solved easily by a preference:
URI: foo.jpeg
Content-type: image/jpeg; qs=0.8
I Tried to find other solutions, but seems there is no way out
currently but using var files or these:
1. either comment out the text/calendar line in the server
configurations.
2. or renaming the ics file in the webwml tree to something like foo-
calendar.lang.ics and make the links match.
any other ideas?
greetings
Jutta
- --
http://www.witch.westfalen.de
http://witch.muensterland.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iEYEARECAAYFAkQJncwACgkQOgZ5N97kHkcUggCeJzqPDMF7SquGuhIsODAab8Fe
YOwAoKYxrjBpC3HuLCq0fKU2JFJWgMfb
=0ws9
-----END PGP SIGNATURE-----
Reply to: