Object reference not set or 404 Errors on any postback depending on location in <modules>

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Object reference not set or 404 Errors on any postback depending on location in <modules>

Bruce Chapman
I have a Url Rewriting module that I distribute. Many people use this module in conjunction with the NeatUpload component as a result of it's inclusion with a popular video uploading component. About 18 months back a few people were reporting problems, which was a 'data length is shorter than content length'. At the time we discussed it via another forum, where another module (a http compression module) was experiencing similar problems That was here :http://www.snapsis.com/Support/tabid/601/forumid/9/tpage/1/view/topic/postid/10918/Default.aspx The solution provided at the time was to move the NeatUpload component above the UrlRewrite component in the list. This was because the UrlRewrite module inspected the Request.Params looking for a specific header. This worked OK and everything was OK for a while. Now, it seems that a new version of NeatUpload must be causing slightly different issues. I recently asked someone to follow that advice (moving the neatupload module entry to the top of the list) but now, if they do that, they receive an ASP.NET 404 error on any POST request that contains Request Data. I'm not sure if this is something new with the later NeatUpload versions, or reflects a change in moving to an IIS7 integrated pipeline server. However, if I move the NeatUpload component below the UrlRewrite component, then I get this exception: Event message: An unhandled exception has occurred. Exception information: Exception type: NullReferenceException Exception message: Object reference not set to an instance of an object. Thread information: Thread ID: 20 Thread account name: NT AUTHORITY\NETWORK SERVICE Is impersonating: False Stack trace: at Brettle.Web.NeatUpload.Internal.Module.FilteringWorkerRequest.ParseMultipart() at Brettle.Web.NeatUpload.Internal.Module.FilteringWorkerRequest.GetKnownRequestHeader(Int32 index) at System.Web.HttpRequest.FillInHeadersCollection() at System.Web.HttpRequest.get_Headers() at System.Web.Configuration.BrowserCapabilitiesFactoryBase.GetHttpBrowserCapabilities(HttpRequest request) at System.Web.Configuration.HttpCapabilitiesEvaluator.EvaluateFinal(HttpRequest request, Boolean onlyEvaluateUserAgent) at System.Web.Configuration.HttpCapabilitiesEvaluator.Evaluate(HttpRequest request) at System.Web.Configuration.HttpCapabilitiesBase.GetBrowserCapabilities(HttpRequest request) at System.Web.HttpRequest.get_Browser() at System.Web.HttpCookie.SupportsHttpOnly(HttpContext context) at System.Web.HttpCookie.GetSetCookieHeader(HttpContext context) at System.Web.HttpResponse.GenerateResponseHeadersForCookies() at System.Web.HttpResponse.UpdateNativeResponse(Boolean sendHeaders) at System.Web.HttpRuntime.FinishRequestNotification(IIS7WorkerRequest wr, HttpContext context, RequestNotificationStatus& status) The NeatUpload component version is 1.3.12 (file version 1.3.3449.26126) I included an option on my UrlRewrite module to not inspect the Request Data, which fixes the problem (as long as the NeatUpload is below the UrlRewrite in the modules list), but this is a least-preferred solution as it reduces other functionality. Do you think it would be possible to fix/change the object not set error so that the NeatUpload component can be included as-is without any other changes? thanks Bruce
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object reference not set or 404 Errors on any postback depending on location in <modules>

Dean Brettle
Administrator
The bad news is that I can't fix the 'object not set' error.  AFAIK, any ASP.NET module that monitors upload progress fails to function if the request data has been accessed before it runs.

The good news is that the 404 error can probably be fixed with a configuration change.  First let me give you a bit of background.  NeatUpload maintains the state of an ongoing upload by making HTTP requests from the server to itself.  This allows NeatUpload to maintain the upload state in the user's session without locking the session for the duration of the upload.  Anyway, to make those requests, NeatUpload uses the hostname from the request received from the browser.  In some environments, the server can not contact itself using that internet-facing name.  This causes those server-to-self requests to return 404s (or sometimes other errors) which cause NeatUpload to throw an exception which is, in turn, caught by ASP.NET and logged or displayed as usual.  Note in this case the status code returned to the browser is 500 (I think), not 404, but the error displayed/logged mentions the 404 error code and has a stack trace that mentions a call to "UploadValues".  Assuming that is what your customer is seeing, there are 2 ways to fix it:

Option 1. Change the environment so that the server can contact itself using the internet-facing name.  This can be tested by trying to access the site using the internet-facing name from a browser running on the server.  Presumably, that currently gives a 404/Page Not Found error.  Once the environment is changed so that the site is displayed, the problem should go away.

Option 2. Configure NeatUpload so that it explicitly uses an AdaptiveUploadStateStoreProvider that is configured to use the server-facing name.  Something like this:

<neatUpload ... defaultStateStoreProvider="myStateStoreProvider" ...>
  <providers>
    ...
    <add name="
myStateStoreProvider"
         type="Brettle.Web.NeatUpload.AdaptiveUploadStateStoreProvider,Brettle.Web.NeatUpload"/>
         handlerUrl="http://server-facing-hostname/path_to_app/NeatUpload/UploadStateStoreHandler.ashx"/>
    ...
  </providers>
</neatUpload>

Either way, the user should upgrade to the latest version of NeatUpload (currently 1.3.21).  It contains only fixes, some important, relative to 1.3.12.  To upgrade, he needs to copy NeatUpload-version/dotnet/app/bin/*.dll into his app/bin folder and copy NeatUpload-version/dotnet/app/NeatUpload/* into his app/NeatUpload folder.

Hope that helps.

P.S. One thing I don't quite understand...  You said, "I included an option on my UrlRewrite module to not inspect the Request Data, which fixes the problem (as long as the NeatUpload is below the UrlRewrite in the modules list)".  I can see how that would fix the "object not set" error and make things work properly on your machine, but I would still expect the 404 errors in your customer's environment.  Can you confirm that you were doing that test on your machine?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object reference not set or 404 Errors on any postback depending on location in <modules>

Guest-1104
Dean thanks for the reply. I'm not sure that your description of the 404 error matches what I am seeing. It is correct that stopping the reading of the Request data stops the object not set error, and moving the request down below the Url Rewriter stops the 404. I have been testing on a localhost, but the customer who reported the issue was on an internet-visible machine. Unfortunately, due to the dynamic nature of the Urls in the application, hard-coding the domain name is quite problematic (though not impossible). Note that the 404 only happens when there is request data in the request, even if you do a GET instead of a POST Is there a possibility that the act of rewriting the Url affects the component? It's interesting to me that the 404 disappears after the Url is rewritten, which makes me thing that something about the request starting with one url and finishing with another might be responsible in some way. If the NeatUpload component reads the request after the rewriting occurs, then perhaps there is no problem with the 404's because the Url stays the same from when the component first sees it until the request is finished. Also, is there any way of determining if the compnent is throwing an exception? Will it show up in the event log of the server?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object reference not set or 404 Errors on any postback depending on location in <modules>

Dean Brettle
Administrator
Hi Bruce,

I just read the support thread you are currently working.  I agree that the problem is not related to the server being unable to contact itself.  The fact that the 404 error didn't mention UploadValues() was the clue.  This now looks like this issue.  The difference in behavior from our 2008 conversation is due to Integrated Pipeline Mode.  Basically, IIRC RewritePath() only works in Integrated Pipeline Mode if the underlying worker request is an IIS7WorkerRequest, which it won't be if NeatUpload has executed first.  So NeatUpload's BeginRequest handler needs to run after calls to RewritePath() in that environment, but that means that earlier modules' BeginRequest handlers must not inspect the request data.  Can you move your inspection code to a handler that is called after BeginRequest?

To answer your questions/comments:

The 404 only happens when there is a request body because NeatUpload ignores requests that don't have a request body.

The act of rewriting the URL is not affecting NeatUpload.  NeatUpload's replacement of the worker request is affecting RewritePath().

AFAIK, if NeatUpload throws an exception it will treated like any other application exception.  Application_Error will fire and the error will be displayed/logged in accordance with the app's configuration (e.g. <customErrors mode="Off"> will cause the error to be displayed to the user).  I think the 404 errors are the result of RewritePath() choking on a non-IIS7WorkerRequest.


Loading...