broken images and attachments. SSL related.

[tiger@…]

There is a problem in viewing images and dowloading attachments in https mode.

Symptoms:

1. Attachment image being show once normally.
2. When you refresh page browser reports that image is broken.
3. Again refresh - image again being shown normally.

This goes in a cyclic fashion.

With attachments also problem that attachment is being cached by the browser. So you often getting stale files after attachment was updated.

I found that that's all related to the cache control headers.

Here is a patch which fixes such behaviour:

Index: trac/web/main.py
===================================================================
--- trac/web/main.py    (revision 2067)
+++ trac/web/main.py    (working copy)
@@ -218,9 +218,12 @@
         self.send_response(200)
         if not mimetype:
             mimetype = mimetypes.guess_type(path)[0]
+
+        self.send_header('Cache-control', 'must-revalidate')
+        self.send_header('Expires', 'Fri, 01 Jan 1999 00:00:00 GMT')
         self.send_header('Content-Type', mimetype)
         self.send_header('Content-Length', stat.st_size)
-        self.send_header('Last-Modified', last_modified)
+        #self.send_header('Last-Modified', last_modified)
         self.end_headers()

         if self.method != 'HEAD':

[eblot]

Related tickets: #529, #1020, #1402

(the above tickets apply to 0.8, not to the trunk)

[tiger@…]

Ok. It's my folt. Things tends to change rapidly... Below patch for the today's trunk.

Index: trac/web/api.py
===================================================================
--- trac/web/api.py     (revision 2184)
+++ trac/web/api.py     (working copy)
@@ -184,9 +184,12 @@
         self.send_response(200)
         if not mimetype:
             mimetype = mimetypes.guess_type(path)[0]
+
+        self.send_header('Cache-control', 'must-revalidate')
+        self.send_header('Expires', 'Fri, 01 Jan 1999 00:00:00 GMT')
         self.send_header('Content-Type', mimetype)
         self.send_header('Content-Length', stat.st_size)
-        self.send_header('Last-Modified', last_modified)
+        #self.send_header('Last-Modified', last_modified)
         self._send_cookie_headers()
         self.end_headers()

[tiger@…]

Any comments?

[cmlenz]

Need to look into this.

[cmlenz]

That patch disables caching which is not an acceptable solution.

[markus]

Our production server runs Trac 0.9 (currently 0.9b1) protected by SSL since quite a while. I've never seen such a behavior (Trac running in CGI mode on ISS6).

However, it is true that when replacing an attachment with a new version but the same filename you'll see the old version until you clear your browser's cache (or explicitly reload the page). But well, I guess this is how caching works... ;-)

[markus]

Erm, I meant IIS6. Our company is located on earth not orbit! :-p

[cmlenz]

Postponing. Probably should mark this one as worksforme (or rather, worksformarkus ;-) ).

[anonymous]

Another data point...

For me, the attachment problem described in this ticket seems to only occur only for small images. I don't know the cutoff, but small JPEGs show the issue. Dimensionally larger JPEGs - which are undoubtedly larger in terms of KB - work fine. As a workaround, when I attach a smaller image, I use BMPs which are uncompressed and therefore more KBs of data. YMMV.

I'm running Safari on Mac OS X 10.4.2, if that matters, and the server is the same OS running Apache 2.0 installed via Fink. I'm still running Trac 0.8.4, and connecting via HTTPS.

[nielsen@…]

I have this problem with version 0.9.2 running as in as a CGI under Apache 2.0.55.

I'm using Firefox with Live HTTP Headers to narrow down the problem. Every second request to get the a CSS (or image) turns up like this:

http://dev/projects/network/chrome/common/css/trac.css

GET /projects/network/chrome/common/css/trac.css HTTP/1.1
Host: dev
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051010 Firefox/1.0.7 (Ubuntu package 1.0.7)
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: trac_session=f4964209c822ff5dc3f3837e
If-Modified-Since: Mon, 05 Dec 2005 18:20:12 GMT
Cache-Control: max-age=0

HTTP/1.x 200 OK
Date: Fri, 23 Dec 2005 22:36:47 GMT
Server: Apache/2.0.55 (FreeBSD) DAV/2 SVN/1.3.0-rc4
Connection: close

• It only occurs when 'If-Modified-Since' is sent from the browser.
• The above patch does suppress the behavior.
• When running under Apache 1.3 the problem does not occur.

[markus]

I'm running TracCgi on IIS in https mode myself and have never seen this reported behavior (as I already said above). To me this seems like it has nothing to do with SSL but with TracCgi and Apache. You can find many error reports about a race condition in Apache when the Browser sends an Is-Modified-Since header. So, I'd rather try to speed up the response header transaction than remove the Last-Modified header part. You may try the following patch below:

Index: trac/web/cgi_frontend.py
===================================================================
--- trac/web/cgi_frontend.py    (revision 2721)
+++ trac/web/cgi_frontend.py    (working copy)
@@ -70,6 +70,9 @@
     def write(self, data):
         return self.__output.write(data)
+    def flush(self):
+        return self.__output.flush()
+
     def get_header(self, name):
         return self.__environ.get('HTTP_' + re.sub('-', '_',
name.upper()))
@@ -81,6 +84,7 @@
     def end_headers(self):
         self.write('\r\n')
+        self.flush()
 class TracFieldStorage(cgi.FieldStorage):

[jornh]

I'm running SSL with a plain old CGI setup on Apache in a Windows environment. I have seen this behaviour with missing images on every 2nd browser refresh for a while with 0.9.4-dev now.

I have just applied the 'flush() patch' suggested above in the comment marked 01/04/06 03:15:30: Modified by markus and it seems to have fixed the problem.

[jornh]

Just to report that the 'flush() patch' still looks like a good solution to this problem in my CGI environment. So I would suggest adding this patch.

[markus]

Thanks for your feedback, jornh. I'm wondering why nobody else responds to this. Does this patch work for others as well?

[nielsen@…]

I've currently moved my production system to mod_python, and (I believe) this problem is not manifested in that configuration. If you really need it tested I can try and rustle up a test system and spend a little time looking into it. However it's likely this won't be until the week after next.

[cmlenz]

I've added the flush in [2902] and [2903]. In addition, I've fixed the date format used for the Last-Modified/If-Modified-Since header, which fixed the reload issue with Firefox and CGI for me.

Please reopen if you're still seeing the problem using trunk, 0.9-stable or 0.9.4.

[anonymous]

I tried the flush fix and the date format fix separately, and it was the date format fix that worked for us here. Thanks, cmlenz.