It's been a few weeks since I contacted support, but over the course of several back & forths with configs and settings they eventually asked me for a stack trace of the object reference error.
This led me to work with one of my colleagues (who had been delving into Tridion's logging of late) to tweak the logging configuration in order to see the stack-trace output. Unfortunately, after reporting the problem to support I reset the environment I was working on (as I've also been working on upgrading to Tridion 2011) and when they made this request SiteEdit was not logging in the Application event log as its configured to do (I'm thinking it's possibly a permission issue).
To get the stack-trace, my colleague changed the \Tridion\SiteEdit 2009\tridion.logging.config to log to a file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" />
</configSections>
<loggingConfiguration name="Logging Application Block" tracingEnabled="true" defaultCategory="General" logWarningsWhenNoCategoriesMatch="false">
<listeners>
<add name="Log File" fileName="C:\Tridion\log\SiteEdit.log" formatter="Tridion Text Formatter" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" traceOutputOptions="None" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" />
</listeners>
<formatters>
<add template="{timestamp} <{win32ThreadId}> {message}" type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" name="Trace Text Formatter" />
<add template="{message}

Component: {keyvalue(component)}
Errorcode: {keyvalue(errorcode)}
User: {keyvalue(username)}

{keyvalue(stacktrace)}" type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=2.0.0.0, Culture=neutral, PublicKeyToken=349a39f202fa9b53" name="Tridion Text Formatter" />
</formatters>
<categorySources>
<add switchValue="All" name="General" />
</categorySources>
<specialSources>
<allEvents switchValue="All" name="All Events">
<listeners>
<add name="Log File" />
</listeners>
</allEvents>
<notProcessed switchValue="All" name="Unprocessed Category" />
<errors switchValue="All" name="Logging Errors & Warnings" />
</specialSources>
</loggingConfiguration>
</configuration>
Once logging was configured to write out to a file, we were able to see the exception's stack-trace:
Error reading from the incoming request.
Object reference not
set to an instance of an object.
Component:
SiteEdit.Proxy
Errorcode: 0
User: NT AUTHORITY\IUSR
StackTrace Information Details:
at
Tridion.Web.UI.SiteEdit.Proxy.Helper.CopyRequestCookies(HttpRequest
request, CookieContainer cookieContainer)
at
Tridion.Web.UI.SiteEdit.Proxy.Request.RequestFactory.CreateRequest(HttpRequest
request)
at
Tridion.Web.UI.SiteEdit.Proxy.Request.RequestFactory.CreateRequest(HttpRequest
request)
at
Tridion.Web.UI.SiteEdit.Proxy.RedirectModule.context_BeginRequest(Object
sender, EventArgs e)
Since the object reference error was in a method entitled "CopyRequestCookies" we decided to look at our cookies (which made sense since closing and reopening the browser caused SiteEdit to work again, but only for a single request).
Sure enough, we had a strange cookie that was being used to simply validate a user had cookies turned on. The javascript code (which I think my developer got from somewhere online) was:
document.cookie = 'CookieTest';
if (document.cookie == "") {
$("form").append('<div class="master-error"><p>Cookies are not enabled</p></div>');
}
Notice the cookie does not have a value (typical JS would be document.cookie = 'name=value';). We're thinking that in the Proxy logic where it is passing the cookies submitted for the proxy site to the staging site, there is some code that is not anticipating a cookie with no value (in Fiddler you can see that the cookie is simply passed as "CookieTest;") but is not defensively coded to handle the scenario.
By changing our code to apply a value to the cookie document.cookie = 'CookieTest=true' the SiteEdit proxy is working properly.
