Some servers perform write-caching which prevents us from writing our status logfile during the upload; it doesn't actually hit the disk until the upload is complete, making it worthless for reporting on progress during the upload.

On every Apache server where we've seen this problem (which is less than 10) of the progress bar not working even though the upload completes successfully, there has been a simple solution: create a file called .htaccess (that's a period followed by "htaccess") either in the directory where the FileChucker CGI script is at, or in some directory above it (like your server's DOCUMENT_ROOT, i.e. the top-level of your webspace).  Then put these lines into that file:

<IfModule mod_security.c>
	# Turn off mod_security filtering.
	SecFilterEngine Off

	# The below probably isn't needed,
	# but better safe than sorry.
	SecFilterScanPOST Off
</IfModule>

If that doesn't work, try it without the 2 IfModule lines.

I think any of your poor users who are forced to do this on the abomination that is IIS might find this useful:

Two things, the IIS 6 metabase has a cgi timeout value that needs to be bumped way up (defaults to 300 seconds; way too short)

The script errors seem to be related to loading a cached copy of the page and/or IE security settings

Also, there is a registry entry in windows 2003 that fixes the write cache issue:

DisableMemoryCache
Registry Path:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters

Data Type: REG_DWORD
Default Value: 0 (disabled)
Range: 0 - 1
Disables server caching.

And I found that setting content expiration to immediate AND doing a manual refresh helps to make sure the log file is written correctly if I do another upload after one completed, I think putting in a meta refresh at the top of the html might help that as well........

-- Anonymous

If you're running OS X Server and the progress bar isn't working, it could be because of "performance cache."  Apparently if ANY of your hosted sites are using the OS X performance cache, then by default, all sites (domains) will attempt to.  The fix then is to disable the performance caching on all hosted sites, using the OS X Server Admin tools/settings.

Around line 30 you'll see:

Some OS X Server users may need to change the single-quotes to double-quotes on that line.  Thanks to Cameron Mitchell & Raoul Callaghan for the tip.

I examined the headers of the server Responses and found out, that the ones from your installation were slightly different to ours.

Yours:
HTTP/1.1 200 OK
Date: Fri, 17 Mar 2006 10:32:39 GMT
Server: Apache
Cache-Control: no-store, no-cache
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml

Ours:
HTTP/1.1 200 OK
Date: Fri, 17 Mar 2006 10:27:11 GMT
Server: Apache/2.0.53 (Linux/SUSE)
Cache-Control: no-store, no-cache
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml

In our case IE kept updating the website several times and then stalled. The tool HttpLook made it obvious that no requests were sent by IE any more - obviously because of caching. The trouble is the line "Connection: Keep-Alive". Adding this in Perl did not help, it resulted in the header being sent as "Connection: Keep-Alive, close".

Forums suggest that IE does not work with KeepAlive-connections from SSL-Servers very well. Because of that it is disabled in all standard installations of Apache with SSL. Since we need to protect our uploads, we have to let the cgi run via ssl.

My solution was to allow the KeepAlive-connection for our script only.

The crucial file in our case was vhost_ssl.conf. It's first line had been:

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

Changing it as follows solved the problem:

<FilesMatch "[^(filechucker\.cgi)]">
  SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 </FilesMatch>

I did not encounter any problems with SSL on IE so far but of course I can't be sure about that until more customers with different versions of IE have tested our upload.

-- Till Pape