I'm also experiencing this behavior and I'm not using any CDN service whatsoever. This happens since the 1.1.5 upgrade and it's a Chrome issue. If I disable "Use Full Friendly URL", the issue goes away.
Could be due to some Chrome extension that a lot of people have installed...
http://canyoncollective.com
We've narrowed it down to be reproducible in Chrome, particularly when you refresh the page. It often loads fine to start, but refreshing breaks it.
<title>Canyon Collective</title>
<noscript><style>.JsOnly { display: none !important; }</style></noscript>
<link rel="stylesheet" href="css.php?css=xenforo,form,public&style=7&dir=LTR&d=1369834688" />
<link rel="stylesheet" href="css.php?css=AdvBBcodeBar_TinyMCE,AdvBBcodeBar_css_normal,EWRblock_RawHyperText,EWRblock_RecentSlider,EWRblock_RecentThreads,EWRporta,Gritter,GritterEXTRA,Picasa_BBcode,bb_code_button,bbcm_js,dark_azucloud,discussion_list,facebook,login_bar,nflj_showcase_node_list_items,node_category,node_forum,node_link,node_list,rating,sidebar_share_page,waindigo_last_post_avatar&style=7&dir=LTR&d=1369834688" />
/* --- EWRporta.css --- */
.topRightBlocks,
.midRightBlocks,
.btmRightBlocks { float: none; width: auto; }
.topLeftBlocks,
.midLeftBlocks,
.btmLeftBlocks { float: left; }
.topRightBlocks .section:first-child,
.midRightBlocks .section:first-child,
.btmRightBlocks .section:first-child,
.topLeftBlocks .section:first-child,
.midLeftBlocks .section:first-child,
.btmLeftBlocks .section:first-child { margin-top: 0px; }
/* clearfix */ .topRightBlocks { zoom: 1; } .topRightBlocks:after { content: '.'; display: block; height: 0; clear: both; visibility: hidden; }
/* clearfix */ .midRightBlocks { zoom: 1; } .midRightBlocks:after { content: '.'; display: block; height: 0; clear: both; visibility: hidden; }
/* clearfix */ .btmRightBlocks { zoom: 1; } .btmRightBlocks:after { content: '.'; display: block; height: 0; clear: both; visibility: hidden; }
.centerShift { margin-left: 260px; }
.articleCategories li { display: inline-block; width: 49%; }
.EWRporta_ArticleView .categorySummary
{
padding: 5px;
margin-top: 10px;
border: 1px solid rgb(225, 225, 225);
border-radius: 5px; -webkit-border-radius: 5px; -moz-border-radius: 5px; -khtml-border-radius: 5px;
margin-top: -10px;
margin-bottom: 15px;
}
.EWRporta_ArticleView .categorySummary .categoryEdit { float: right; }
.EWRporta_ArticleView .categorySummary ul { display: inline; }
.EWRporta_ArticleView .categorySummary li { display: inline; }
.EWRporta_ArticleView .categorySummary li::after { content: ','; }
.EWRporta_ArticleView .categorySummary li:last-child::after { content: ''; }
.EWRporta_ArticleView .messageArticle .messageAuthor { padding-bottom: 10px; }
.EWRporta_ArticleView .messageArticle .messageAuthor .avatar { float: left; }
.EWRporta_ArticleView .messageArticle .messageAuthor .messageInfo { margin-left: 65px; padding-top: 30px; }
.EWRporta_ArticleView .messageArticle .messageAuthor .shareControl { float: right; padding-top: 25px; }
/* clearfix */ .EWRporta_ArticleView .messageArticle .messageAuthor { zoom: 1; } .EWRporta_ArticleView .messageArticle .messageAuthor:after { content: '.'; display: block; height: 0; clear: both; visibility: hidden; }
The issue appears to be described here:
http://productforums.google.com/forum/#!topic/chrome/zID6uQQfKH8
Looking at canyoncollective.com, the 304 response is returning a Content-Type of text/html from the server. This should not be happening (it's against the spec). It looks like the web server itself is adding it. This would need to be disabled in the web server; nothing we can really do to prevent it (without violating the spec ourselves).
I'm also suffering this problem since 1.1.5 upgrade.
There was a bug in 1.1.4 that would've prevented it simply because it never actually sent 304s. It was in 1.1.3 though and it has been reported in the past.
When I debugged it, a text/html content type was added to the response headers. This would be coming from the web server or some other proxy between as XF doesn't put them out in the CSS request.
Well that makes me feel better that it isn't just us. Litespeed insists that it is xF coding.
Same here. I've never encountered this issue in 1.1.4. Right now I simply told people don't press F5 on chrome. Maybe I should do a test using a clean 1.1.4 and clean 1.1.5 and see if I can reproduce the results.I'm also suffering this problem since 1.1.5 upgrade.
Well that makes me feel better that it isn't just us. Litespeed insists that it is xF coding.
...Maybe I should do a test using a clean 1.1.4 and clean 1.1.5 and see if I can reproduce the results...
We use essential cookies to make this site work, and optional cookies to enhance your experience.