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

1. create a topic with a Word (or maybe even .odt) attachemnt.
2. try to open with Konqueror.
3. 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:

• from the topic body: http://red/twiki/pub/KnowledgeBase/VGA/vga.doc
• from the attachment list: http://red/twiki/bin/viewfile/KnowledgeBase/VGA?rev=1;filename=vga.doc

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.

1. Both browsers succeed in saving the document to disk when using the viewfile url.
2. Both browsers succeed in saving the document to disk when using the pub url.
3. 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.
4. 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