This affects people when:

• A custom logo is set (eg. in Administration -> Global Logo).
• The server has HTTP keepalives enabled (usually the case)
• You refresh (eg. ctrl-r in Firefox) a page

Then the page load may hang halfway for around 15 seconds, and there may be odd visual problems as if a stylesheet is broken.

The problem is that Confluence is trying to enable browser caching, by sending the logo with a "304 Not Modified" header. Unfortunately it is also sending the image body in the response. According to RFC2616 §10.3.5 "The 304 response MUST NOT contain a message-body". Confluence does. This then causes varying effects:

• If you're serving requests directly from Tomcat's HTTP connector ("Server: Apache-Coyote/1.1" in the HTTP response), everything appears fine. Evidently Tomcat is stripping the bogus body for you:

  jturner@psyche:~$ HEAD 'http://localhost:8081/confluence/download/userResources/logo' | grep ETag
  ETag: "1207190442000"
  jturner@psyche:~$ ETAG="1207190442000"
  jturner@psyche:~$ echo -e "GET /confluence/download/userResources/logo HTTP/1.1\nHost: localhost:8081\nIf-None-Match: \"${ETAG}\"\n" | nc localhost 8081
  HTTP/1.1 304 Not Modified
  Server: Apache-Coyote/1.1
  X-Confluence-Request-Time: 1207191596513
  Last-Modified: Thu, 03 Apr 2008 02:40:42 GMT
  ETag: "1207190442000"
  Date: Thu, 03 Apr 2008 02:59:56 GMT
  
  

• If you're running Tomcat behind mod_jk or mod_proxy_ajp, then the browser sees the "304 Not Modified" header, plus the body that shouldn't be there:

  jturner@psyche:~$ HEAD 'http://localhost/confluence/download/userResources/logo' | grep ETag
  ETag: "1207190442000"
  jturner@psyche:~$ ETAG="1207190442000"
  jturner@psyche:~$ echo -e "GET /confluence/download/userResources/logo HTTP/1.1\nHost: localhost\nIf-None-Match: \"${ETAG}\"\n" | nc localhost 80
  HTTP/1.1 304 Not Modified
  Date: Thu, 03 Apr 2008 03:01:17 GMT
  Server: Apache/2.2.3 (Ubuntu) DAV/2 mod_jk/1.2.18 mod_ssl/2.2.3 OpenSSL/0.9.8c
  ETag: "1207190442000"
  
  �PNGIHDR��a�d�IT    pHYs..........
  

By taking a TCP dump of its interactions with the server:

jturner@psyche:~$ sudo tcpdump -i lo -s 1500 -w port80.pcap "host localhost and port 80"
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 1500 bytes
110 packets captured
220 packets received by filter
0 packets dropped by kernel
jturner@psyche:~$ 

you can see a 15s delay, and the response to the logo request will often have headers after the body content.