Question

When trying to upload files Firefox pops up a dialog that says "Document contains no data".

This only started to occur in the last few weeks after some tweaking of the .htaccess file - however, I've tried rolling those changes back and I've still had no luck. I can upload some files, but anything over about 800k causes this message. I don't have any limits set in either the Apache configuration or the TWiki configuration so it can't be this.

Even more strangely, using the LiveHTTPHeaders extension for Firefox shows that no actual HTTP transaction appears to be happening. However, I find it hard to believe that it is purely Firefox related since even Internet Explorer on a different PC displays an error message.

Does anyone have any ideas?

Environment

-- LanceDuivenbode - 12 Aug 2005

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Not sure what the cause is. See related topics Codev.DocumentContainsNoData, EditPageContainsNoData, CantSaveEditsDocumentContainsNoData, Codev.HangsSavingLargePages, TimeOutSavingTWikiPreferences

-- PeterThoeny - 13 Aug 2005

Ok, I'll continue to look into this further. Until I've a better idea, I'll leave this open.

--LanceDuivenbode - 17 Aug 2005

-- LanceDuivenbode - 17 Aug 2005

We've been having the same problem for months. I spent the past 3 days attempting to track the problem. Fortunately, I believe we have a simple workaround for this which is working just fine here so far.

The problem seems to manifest in both IE6 and Firefox 1.0.6 as a function of the authentication.

In our case after making a successful upload, all future uploads during the same session were trouble-free. The TCP packet order tended to change and was different between FF and IE (odd?) but the conclusion we drew was that the whole situation would be avoided if we could pre-load our browser cache with the Auth data specifically needed for the /upload directory (script as directory.)

Our fix: In the attach template, just above the FORM tag we inserted a hidden, 1-pixel sized image tag with the SRC set to src="/cgi-bin/upload" which caused an additional GET to be sent to the server when the attach page loaded. This GET request was met with a 401 since we had not yet authenticated for upload and was silently answered with a re-request laced with the credentials. This seemed to do the trick as now, when we submit the form with the file selected, the browser is not faced with the challenge of answering the 401 error.

Caveats: a) Adds 2 extra requests that the server has to answer, b) has to be implemented in the attach template for each skin you have, and c) response of the execution of upload without params forces an additional request for the OOPs page. We may answer caveat 'c' by modifying the upload script to accept a bypass param (or something similar in the path info) that would force it to spit back blank image data and stop. But at least the uploads are working now

LiveHTTPHeaders was useful for the most part but was useless at the exact time that this error occurred. What I found more beneficial was to use Ethereal to sniff the HTTP and TCP packets on port 80 of my network adapter.

Also, the popup dialog box "Document contains no data" is useless. Turning on the real error pages is much more useful for situations like this. You can do that by entering 'about:config' (without the quotes) in the ADDRESS/URL field in Firefox and hitting enter. Then double-click the 'browser.xul.error_pages.enabled' setting so that it is TRUE. Now you will likely get "Net reset error". The TCP discussion on this could probably take many more pages so I'll leave that alone for now.

-- WesleyCraft - 23 Sep 2005

I just want to add in my environment info. for comparison.

SunOS 5.8, Perl 5.8.7, Apache 1.3.33, TWiki 01 Sep 2004 rev:1742 - Plugin API v1.025, Firefox 1.0.6 rev 1.7.10, IE 6.0.2800.1106, Win XP Pro SP1

-- WesleyCraft - 23 Sep 2005