Cookie Header With WebPlayer Unity3d 4.3

Questions & Answers
1

Setting the cookie header with webplayer worked in Unity 4.2 but fails in Unity 4.3.

To replicate

            var headers = new Hashtable{{"Cookie", "CookieValue" }};
            var www = new WWW("http://google.com", new byte[1], headers);    
            yield return www;

The error message is

ArgumentException: Cannot overwrite header: Cookie

UnityEngine.WWW.CheckSecurityOnHeaders (System.String headers) (at C:/BuildAgent/work/d3d49558e4d408f4/Runtime/Export/WWW.cs:67)
UnityEngine.WWW…ctor (System.String url, System.Byte postData, System.Collections.Hashtable headers) (at C:/BuildAgent/work/d3d49558e4d408f4/artifacts/EditorGenerated/Utils.cs:72)

I read the change log for 4.3. It had no mention of this change. Not sure what to do, authentication cookies are kinda important to me.

2

I have a work around. Dont use Cookies to authenticate. You could use basic authentication for instance - and encode the username and password into a header field.

I ended up injecting my authentication cookie into the header and then augmented my server code to reattach it as a cookie to the request before authentication took place. Kind of an odd solution, but I can reuse all my cookie dependent authentication stuff.

3

How to fix this: Clear the generated folders, like library, temp and object.

Steps to replicate the bug and solution:

  1. Install unity 4.2.
  2. Create a new project ‘A’ using 4.2, note that op’s code works.
  3. Upgrade to unity 4.3.
  4. Create a new project ‘B’ using 4.3, note that again op’s code works.
  5. Open and upgrade the 4.2 project ‘A’ to 4.3, note you get the Exception.
  6. Clear the generated folders in project ‘A’, note that op’s code works.

I guess unity 4.3 has a updated library but does not update/invalidate generated code when it upgrades the projects.

4

For anyone else still struggling with this problem:

For me, it seems to only affect the Editor when running with WebPlayer as the build target (which, if your project is a web one, is probably most of the time!). To avoid the problem and get on with your development, simply switch the build target to PC & Mac Standalone, and the issue goes away. When deploying, you then need to simply switch it back - it doesn’t seem to affect deployed WebPlayer builds, only in the Editor. Of course, if this does seem to affect your deployed builds, you can always nuke your temporary directories and re-deploy - which at least you’ll have to do far less frequently.

I’m posting this as an answer on the grounds that it’s arguably a workaround. It’s also possibly an explanation for GeorgeCrane’s directory-nuking solution above, as one of the files in there stores the current build target - so by deleting them, the build target is reset to Standalone, which then appears to work.