#2006 closed defect (fixed)
broken images and attachments. SSL related.
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | 0.9.4 |
Component: | general | Version: | devel |
Severity: | normal | Keywords: | https ssl broken images attachments |
Cc: | tiger@…, nielsen@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
There is a problem in viewing images and dowloading attachments in https mode.
Symptoms:
- Attachment image being show once normally.
- When you refresh page browser reports that image is broken.
- 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':
Attachments (0)
Change History (19)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
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()
comment:5 by , 19 years ago
Component: | browser → general |
---|
That patch disables caching which is not an acceptable solution.
comment:6 by , 19 years ago
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… ;-)
comment:8 by , 19 years ago
Milestone: | 0.9 → 0.9.1 |
---|
Postponing. Probably should mark this one as worksforme
(or rather, worksformarkus
;-) ).
comment:9 by , 19 years ago
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.
comment:10 by , 19 years ago
Milestone: | 0.9.1 → 0.9.2 |
---|
comment:11 by , 19 years ago
Cc: | added |
---|
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.
comment:12 by , 19 years ago
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):
comment:13 by , 19 years ago
Milestone: | 0.9.3 → 0.9.4 |
---|
comment:14 by , 19 years ago
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.
comment:15 by , 19 years ago
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.
comment:16 by , 19 years ago
Thanks for your feedback, jornh. I'm wondering why nobody else responds to this. Does this patch work for others as well?
comment:17 by , 19 years ago
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.
comment:18 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:19 by , 18 years ago
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.
Related tickets: #529, #1020, #1402
(the above tickets apply to 0.8, not to the trunk)