I need some assistance
again please.
Solving the original problem I had (see link above) has now created a new problem but I don't why it's happening. On the dedicated web server (configuration at the end of this post) wile using FF, I'm getting a message that states "The connection was reset" when requesting a page that has 14 file upload controls on the page. If I keep trying to access the page, I'll eventually (a couple of tries later) get "HTTP Error 503. The service is unavailable" and won't be able to access the site until the app pool is reset. This does not happen on pages where I use only one upload control.
This never happened with the AjaxUploader 3.0 20090518, only with AjaxUploader 3.0 20090827. In
referencing this KB post, I made the following changes in web.config:
appSettings
- # <add key="CuteWebUI.AjaxUploader.TempDirectory" value="\\computername\TempFolder"/>
- # <add key="CuteWebUI.AjaxUploader.WindowsUsername" value="userAccount" />
- # <add key="CuteWebUI.AjaxUploader.WindowsPassword" value="userPassword" />
- # <add key="CuteWebUI.AjaxUploader.WindowsDomain" value="companyDomain" />
system.web
- <securityPolicy>
- <trustLevel name="Full" policyFile="internal" />
- </securityPolicy>
The KB post also had some info about the page lifetime being affected by altering the trust level. It's not clear to me what is trying to be communicated here. Maybe this is something I need to look at?
If I run this locally (XP machine using Cassini), I get a System.Web.HttpException, "An error occurred while attempting to impersonate. Execution of this request cannot continue." with the following stack trace:
at System.Web.ImpersonationContext.GetCurrentToken()
at System.Web.ImpersonationContext.ImpersonateToken(HandleRef token)
at System.Web.ApplicationImpersonationContext..ctor()
at System.Web.HttpRuntime.FinishRequest(HttpWorkerRequest wr, HttpContext context, Exception e)
at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)
at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr)
at System.Web.HttpRuntime.ProcessRequest(HttpWorkerRequest wr)
at Microsoft.VisualStudio.WebHost.Request.Process()
at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
at Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object acceptedSocket)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)
I'm wondering how the component impersonation works. Does the network traffic to the temp folder use the supplied account? Or is it the entire page or application?
Here are the other relavent web.config settings:
system.web > pages > controls
- <add namespace="CuteWebUI" assembly="CuteWebUI.AjaxUploader" tagPrefix="CuteWebUI"/>
system.webserver > modules
- <remove name="CuteWebUI.UploadModule" />
- <add name="CuteWebUI.UploadModule" type="CuteWebUI.UploadModule,CuteWebUI.AjaxUploader"/>
Couple of notes about the environment. This site is a virtual directory in the root of the domain. It's typically a mirror of what we have in production and we use it as a staging environment. Since production is using the older component and configuration (I haven't released this version yet) they are not currently the same and production doesn't suffer from this problem. This is why I have the "remove" statement in the system.webserver > modules node in web.config. We're using Windows Server 2008, IIS7 running in a separate app pool in Integrated mode.
This is as much info as I've been able to gather. I'm hoping you can setup a test and try for yourselves.
Thanks,
David