I am getting an error message in Chrome that says 'Refused to set unsafe header "Connection"' on several websites that we have deployed to their live server. we do not see any problems with this during local development or when the site is on a staging server behind our firewall.

when we receive this message it seems to be when we start a new browsing session, and when we log into the cms we notice that complextablefields do not load correctly, and it looks like they are missing their styling. (this is when we receive the error). if we refresh the browser the error message goes away and everything seems to run fine until the next session.

i saw some other posts saying to check for extra carriage returns after the closing ?> php tag, but i'm using short tags and dont have the closing php tag just for this reason.

also, this only happens at work. if i log in from home or on another network i don't see the error message.

any ideas what could be causing this?

thanks,
-Chris

I get the same error, but I also get it in my local dev environment (using MAMP). I believe this error is isolated to Chrome, as I've never seen this error in any other browser.

Also this error has not affected any styling and my complexTableFields load just fine.

I kind of assumed that this had something to do with my work firewall, as I don't get this at home either, but I'm starting to wonder if it has something more to do with my addons or something in chrome rather than SilverStripe.

its browser independent for me. i get the problem with firefox, ie, safari, and chrome on any silverstripe cms outside our network. chrome is the only browser that reports the error though, but chrome seems better at reporting errors than any other browser and/or plugin (even firebug). (i realized this when working with html5 offline data storage and its about the only useful browser for debugging cache manifest problems).

have you seen this post? the writer eliminated carriage returns after the closing php ?> tag and it fixed things for them. i am not including the closing ?> tag in my php as silverstripe recommends using short tags to avoid problems like this, so this solution doesnt work for me unfortunately, but it may help you.

yeah I've seen that post, but I too don't use closing tags in my php files.

Now I'm really interested in finding more out about this error.
I wonder, do you get the same error on a fresh install of SS with NO added modules or widgets?

I havent tried.. i never really interact with a fresh installation of silverstripe in a production environment. i'll have to run a test shortly.

i am also met the same question.

i tested this on a new installation of silverstripe (2.4.5) and needed to slightly customize page.php to provide a CTF in getCMSFields, but i do see the Refused to set unsafe header "Connection" error.

some odd clues:

• i get this error message whenever i load a tablefield, in the security section or the Site pages section. even if i refresh the browser, i still get the error messages.
  
• 
  
• if i open chrome and log in, in the pages section i see tablefields that look like they do not have styles applied to them, but if i refresh the browser they do have styles applied to them. in the security section, everything looks fine (but i still get the error).
  

are you guys seeing the same thing?
-Chris

I've been trying to read up on this error as well, only to find out that I know far too little about http :-( So ignore if you think this is nonsense...

I suppose this does have something to do with the Connection header. The only place I actually see it being set is somewhere in prototype.js:

if (this.transport.overrideMimeType)
        requestHeaders.push('Connection', 'close');
}

This is definitely being called on pages containing a CTF (checked with an alert('*******'); ). Removing it is no option, since the CMS won't load, it seems. So I was wondering: what if you were to replace the CTF with a DataObjectManager, that doesn't use ProtoType, just to check?

It seems in HTTP prior to 1.1, setting Connection: close is not supported. I don't know if this is true (please guru's) but just to check - do your problemservers return HTTP1.1?