NeatUpload Incompatibilty

Hi John

I'm just investigating NeatUpload incompatibilty with my own software, which is implemented as a Http Module.  It's well documented that NeatUpload and PageBlaster have incompatibilities.    I was just wondering if you ever actually investigated the issue much at all? 

I have been able to recreate the problem running the NeatUpload version that gets bundled with UVG, and it seems to throw a 'data length (0) is shorter than content-length (xx) error' when my software is checking the Request.Params collection for a value.

My question is this : does PageBlaster do something similar during processing ?  (ie, look for a value in the Request.Params collection)

Any info you have might be illuminating and fix this problem for both of us.

thanks

Bruce

Hi,

I'm the author of NeatUpload and would be happy to work with either of you on these compatibility issues.  FYI, I've successfully worked with the UVG author on UVG/NeatUpload compatibility.

Regarding the points that have been raised so far in this thread:

1. If your module checks Request.Params (or other properties of Request), it needs to run after NeatUpload's UploadHttpModule.  That is because NeatUpload (and any other module that monitors upload progress) needs to intercept the request before ASP.NET reads the request body.  ASP.NET needs to read the request body in order to compute Request.Params.  So if you access Request.Params before NeatUpload intercepts the request, ASP.NET will read the request body and when NeatUpload tries to read the request body, there won't be anything there.

2. NeatUpload doesn't and can't use a ResponseFilter because it needs to intercept and monitor the incoming request not the outgoing response.

3. NeatUpload uses ASP.NET's path-based location filtering to control which requests it intercepts.  For details, see Using Location Filtering to Restrict/Modify NeatUpload's Request Processing.

I hope that helps.  Please feel free to contact me with further questions, either by posting to this thread, starting a thread in the NeatUpload help forum or by emailing me (dean at brettle dot com).

Dean

THanks for the explanation.

I think the key is to restrict the neatUpload HttpModule to certain calls, as you have specified how to do.  For your information, your module is bundled with another module called 'Ultra Video Gallery', it's the ultra video gallery that installs NeatUpload into the DNN instance.

Can you clarify if the asp.net location path attribute will match a rewritten Url, or does it match on an actual file?

-Bruce

Err I just re-read the former post and realised you've already been speaking to Pengsten.  Sorry about that, I do read things, honestly, I do...

Hi Dean,

Thanks for joining in on the conversation and your offer to work with us.

Is there a way we can tell specifically if a request is for upload using the NeatUpload module?  I understand that the request.params collection cannot be read before NeatUpload gets the request, but if I could read something in the request then I could bypass those completely. 

Maybe it is just a matter of putting the NeatUpload module at the top of the httpModule list, and then other httpModules could read something  in the request maybe even something that you put on the Context as a flag.

To answer your specific question I need to give a you a little background.  In the BeginRequest event, the UploadHttpModule intercepts all requests for which useHttpModule="true" (the default) in the applicable element of the Web.config.  For each of these requests it creates a child request which proxies calls to the original request object (filtering and monitoring as necessary) and prematurely terminates processing of the original request (via a call to CompleteRequest()).  The child request is then passed through the ASP.NET pipeline via a call to HttpRuntime.ProcessRequest().  So, when the UploadHttpModule is being used, all requests are replaced with proxy child requests. 

All HttpModules are called as usual for the child requests, including the UploadHttpModule.  The UploadHttpModule mostly ignores the child requests (since the actual filtering/monitoring is done by the child requests themselves), but the UploadHttpModule BeginRequest handler does set HttpContext.Current.Items["NeatUpload_origContext"] to the HttpContext object associated with original request.  I use that internally and don't consider it part of the public API at this point.  If you find that you need it to achieve compatibility, please let me know why/how so we can work something out that you can rely on in future releases.

Having said all that, if you put the UploadHttpModule before the modules that access the Request object, I think those modules might work properly as-is.  Have you tried that?  If so, what sort of errors/problems are you encountering?

--Dean

Dean

I haven't tried changing the order myself, as I haven't been able to consistently reproduce the problem, I'm worried about false positives.  However, hopefully someone afflicted with the problem can try this and post back?

-Bruce

I was using 1.2.25 as bundled with Ultra Video Gallery, however, the inconsistency was due to my environment rather than the code. I had set it up using a Cassini webserver as I was doing some other, unrelated, testing at the time. I'm pretty sure it was because of the environment instability that I had trouble with the consistency. It was enough for me to deduce that it was the request.params call that was causing the problem. I have since deleted this test environment.

[edit : fixed version from 1.2.5 to 1.2.25)

Im running DNN 4.8.2 and UVG 2.3 in a localhost environment with the latest version of PB.

Had the same problem with NeatUpload once PB was installed. I commented out all instances of NeatUpload and was still able to upload videos fine just without a progress bar. Since reviewing this thread, I've done this:

1. Enabled neatupload in web.config
2. Moved it to the top of the httpmodules list, above PB.

Tried to upload an avi file at 4.88 mb and got this error:
The MaximumValue cannot be less than the MinimumValue 00:00:00 of RangeValidator1.

Next I tried to upload a wmv file at 5.2 mb and was successful with no errors

In my web.config file, I have:
httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="90000" requestLengthDiskThreshold="90000" executionTimeout="352"
for the standard DNN

and:
neatUpload useHttpModule="true" maxRequestLength="90000" defaultProvider="FilesystemUploadStorageProvider" maxNormalRequestLength="90000"
for neatupload

As previously stated by Bruce, NeatUpload is bundled with my version 2.3 of UVG.

I will double check on the avi file to make sure it uploads with neatupload commented out, but I dont think it would be the problem. I seem to remember UVG has a problem with some of my avi files.

Many thanks for testing this.  The error is definitely not being thrown by NeatUpload.  As you mentioned, it is probably a UVG bug or perhaps a legitimate problem with the AVI file.  If you find that commenting out NeatUpload solves the problem, please post here or otherwise let me know.  Assuming the avi problem isn't related to NeatUpload, your second test seems to indicate that putting NeatUpload before PageBlaster makes them compatible with each other.

--Dean

I have also tried shifting the NeatUpload entry to the top of the list in the HttpModules section, and this seems to have solved the problem on a clients site.  I also set up my test environment again to test a related problem, and shifting the location also solved the problem.  Note that in these two cases, Page Blaster wasn't installed, I'm referring to the use of the Url Master module.  This module shares the problem with PageBlaster as both attempt to read from the request.params collection before the NeatUpload component has had a chance to read the request.

So, for most people, I think shifting hte order of the NeatUpload httpmodule would appear to be the solution.