system
Fedora 6,
OpenOffice 2.0.4, firefox 1.5.0.9 and Konqueror 3.5.5
The problem
An attached MS doc file cannot be opened if browsing with Konqueror, but it can if browsing with Firefox.
Details
The error message, as given by
OpenOffice, is
Error reading data from the internet. Server error message: 403 Forbidden.
Error given by the Apache:
[Tue Jan 09 16:07:51 2007] [error] [client 192.168.7.58] client denied by server configuration: /var/www/twiki/bin/viewfile
How to reproduce
- create a topic with a Word (or maybe even .odt) attachemnt.
- try to open with Konqueror.
- try to open with FF.
Some analysis.
Other type of attachments, such as .jpeg .pdf .zip, open nicely.
if I copy the link of the attachment (
http://red/twiki/bin/viewfile/KnowledgeBase/EyeRelief?rev=1;filename=eye_relief_-_LED.doc
) and use
wget
to get the file, I can then open it with OOo.
But if I
directly try to open the with the command
oowriter
http://red/twiki/bin/viewfile/KnowledgeBase/EyeRelief?rev=1;filename=eye_relief_-_LED.doc
I get the same error as before.
This sounds very much like an issue with your server configuration. Or it might be a Konqueror bug (we have seen others). I don't use Konqueror, but I do use a wide range of other browser (FF, Opera, Epiphany, IE) in testing, and haven't seen this.
Can anyone else verify this please?
CC
News: I found that clicking on the attachment from a link in the topic
does open the attachment successfully. clicking on the attachment from the list of attachments at the end of the topic, however brings the above mentioned error message.
Here are the two URL I get for the same attachment:
In Firefox I also see the same difference in links.
In addition, as mentioned before, this is only an OO.org issue. All other applications i tried so far have no such problem.
Tested on TWiki engine 4.1.1
-- yuval.
There is another bug item raised recently where it is proposed changing the link in the attachment table back to using the direct pub directory. I bet this would also resolve this issue - at least when viewing the latest rev. It is the horror url that viewfile uses that gives problems for browsers because the filename becomes part of the query string instead of the path of the URL.
--
KennethLavrsen - 13 Feb 2007
I've been tracing this now using both Konqueror and Firefox on Linux, with both the
viewfile
and the
pub
URL.
The differences seem to be caused by a different interface between Konquereor and OOwriter, as compared to Firefox and OOwriter (I am using OpenOffice writer to display the
.doc
file in both cases), and by the inability of TWiki to differentiate between the request methods
GET
and
OPTIONS
.
- Both browsers succeed in saving the document to disk when using the
viewfile
url.
- Both browsers succeed in saving the document to disk when using the
pub
url.
- Both browsers succeed in passing the document to OOwriter when using the
pub
url.
- With Firefox, there is just one request:
GET /twiki/pub/Sandbox/DocAttachment/foo.doc
(code 200)
- With Konqueror, there are a couple of requests:
GET /twiki/pub/Sandbox/DocAttachment/foo.doc
(code 200)
OPTIONS /twiki/pub/Sandbox/DocAttachment/foo.doc
(code 200)
GET /twiki/pub/Sandbox/DocAttachment/foo.doc
(code 200)
PROPFIND /twiki/pub/Sandbox/DocAttachment/foo.doc
(code 404)
The OPTIONS
, GET
, and PROPFIND
requests do not show a user-agent field in the log file.
- When trying to pass the document to OOwriter using the
viewfile
url:
- With Firefox, there is just one request:
GET /twiki/bin/viewfile/Sandbox/DocAttachment?rev=1;filename=foo.doc
(code 200)
- With Konqueror, there are a couple of requests:
GET /twiki/bin/viewfile/Sandbox/DocAttachment?rev=1;filename=foo.doc
(code 200)
OPTIONS /twiki/bin/viewfile/Sandbox/DocAttachment?rev=1;filename=foo.doc
(code 404)
PROPFIND /twiki/bin/viewfile/Sandbox/DocAttachment?rev=1;filename=foo.doc
(code 404)
HEAD /twiki/bin/viewfile/Sandbox/DocAttachment?rev=1;filename=foo.doc
(code 404)
The OPTIONS
, PROPFIND
, and HEAD
requests do not show a user-agent field in the log file.
So apparently the failure of TWiki's
viewfile
routine to properly respond to the
OPTIONS
request is causing the difference. Plain Apache, as in the
pub
url, seems to deliver an empty (Content-length: 0) reply with an
Allow:
header. TWiki's
viewfile
, on the other hand, spits out the complete file as content, but lacks the
Allow:
header. Maybe Apache doesn't like that and converts TWiki's response to a 403 code (because
nothing is in the
Allow:
header), which in the logfile of
my installation is being converted into a 404 because I lack a proper error document (I am seeing the 403 code when I hack the URL into telnet).
I've occasionally cursed about TWiki not looking at
$ENV{REQUEST_METHOD}
(or its equivalent from
CGI.pm
) when a
HEAD
request took as long as a
GET
, but apparently the situation with
OPTIONS
requests can have even worse consequences than just a delay if a client combination like Konqueror/OOwriter tries to apply WebDAV techniques.
--
HJ
OPTIONS, PROPFIND and HEAD are what I would expect to see if the browser was expecting a
WebDAV operation. However TWiki doesn't respond to either of these requests. Normally Konqueror only does (did) this when a
webdav:
protocol was given; maybe it's getting it's kickers in a twist.
Make sure first that
WebDAVPlugin is not installed. Then check if the standard Apache webdav is enabled, and try disabling it. That might give you some pointers.
CC
No, I didn't have
WebDAVPlugin, nor Apache's dav modules. But anyway - my conclusions were wrong. This seems to be an issue between OOwriter and TWiki's default configuration.
I get the same error message if I try to open the document with the
viewfile
URL directly in OOwriter, but as expected it "works" if I use the
pub
URL. This suggests that the interface between Konqueror and OOwriter is simply to pass the URL. Firefox, on the other hand, saves the document in
/tmp
and passes that filename (both can be verified by looking at the document's properties if opened in OOwriter).
So I wondered why Apache would reject
OPTION
requests for the
viewfile
, but not for the
pub
URL and finally found the reason in my own configuration file. Recalling from above: "The
OPTIONS
,
PROPFIND
, and
HEAD
requests do not show a user-agent field in the log file." - and the configuration file had the following line only for
bin
, but not for
pub
:
Deny from env=anonymous_spider
OOwriter behaves like an anonymous spider in not delivering a User-Agent header, so Apache treats it like an anonymous spider. If I remove the above line from my configuration, then Konqueror can open
.doc
attachments with the
viewfile
URL quite fine.
It looks like CC was exactly right when saying:
This sounds very much like an issue with your server configuration. Or it might be a Konqueror bug (we have seen others). But I am now optimistic that we know
which server configuration, and
which bug.
I'm setting to Waiting for Feedback so that Yuval can check whether he has the anonymous_spider line in his configuration - either in
httpd.conf
files or in
bin/.htaccess
. If he has, we can close this item and file a bug against OOwriter.
--
HJ
no response from Yuval, so closing this under the 30 day rule.
CC