Re: Apache delivering the wrong file
Ah, the joys of Apache content negotiation... :-7
Before I say anything else: I have been working with Apache 2 for a long
time now, some of the stuff may not work with Apache 1.3. (BTW, switching
to v2 on debian.org would give us lots of benefits, *nag* *nag*)
I agree that lynx is wrong - apparently the developers have not paid close
attention to the HTTP RFC: The order of entries in the Accept header is not
significant.
> Do you think it's feasable to create type-map files for all event
> files within the .../events/ directory?
Wouldn't this be awkward because the .var extension would have to appear in
all links?
> If not, do you see a different approach to fix this problem?
Yes, there are a few ideas that spring to mind:
1) AddType application/octet-stream .ics
Not ideal because you'd have to save the .ics to a file and only then
import it into whatever tool you are using.
2) RemoveType .ics
Apache 2-only, will cause .ics files to be ignored by MultiViews. Same
problem as above.
3) Simply rename the .ics files so MultiViews skips over them, i.e. do not
have foo.en.ics alongside foo.en.html, but use foo-date.en.ics or
similar.
4) AddType text/calendar;qs=0.9 .ics
This is not well documented, but it works!
(At least I know it does with Apache 2.)
5) Make the .ics files bigger (larger file size) than the corresponding
.html files! This may sound weird, but that's OK, because it is. It is
described as the 8th point under
<http://httpd.apache.org/docs/2.2/content-negotiation.html#methods>
I'm not sure about Apache 1 vs 2.
HTH,
Richard
--
__ _
|_) /| Richard Atterer | GnuPG key: 888354F7
| \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7
¯ '` ¯
Reply to: