How to configure IIS7 to allow zip file uploads using classic asp?

[Kal]

I recently installed Windows 2008 Server to replace a crashed hard drive on
a web server with a variety of web pages including several classic ASP
applications. One of these makes extensive use of file uploads using a com
tool that has worked for several years.

Under IIS7 doc files and jpeg files upload as before, but zip files give a
500 error. This works the same with the firewall on and off.

 

[Anthony Jones]

I recently installed Windows 2008 Server to replace a crashed hard drive on
a web server with a variety of web pages including several classic ASP
applications. One of these makes extensive use of file uploads using a com
tool that has worked for several years.

Under IIS7 doc files and jpeg files upload as before, but zip files give a
500 error. This works the same with the firewall on and off.

And what does your event log tell you?

Is this 64bit install? If so is the App Pool 64 bit or 32 bit?
Do you have third party ISAPI filters? If so are you using integrated or
classic pipeline?

 

[David Wang]

I recently installed Windows 2008 Server to replace a crashed hard drive on
a web server with a variety of web pages including several classic ASP
applications. One of these makes extensive use of file uploads using a com
tool that has worked for several years.

Under IIS7 doc files and jpeg files upload as before, but zip files give a
500 error. This works the same with the firewall on and off.

This does not seem like an IIS issue because you say doc and jpg files
upload as before -- if the COM tool handles the upload as HTTP entity
body, IIS certainly does NOT care if the source bytes came from a doc,
jpg (compressed graphics), or zip file.

If you see change in behavior, it is usually due to some hacky
behavior being employed by the COM tool or ASP app to make it work. It
really doesn't matter if it worked before, if it worked by accident.
One really has to look at the HTTP traffic involved on the request to
make the judgement of correctness.

You can turn on Failed Request Tracing to determine if it is any IIS
module returning the 500 error. If the 500 error comes from processing
the ASP page itself, then that's where I'd investigate. Perhaps you've
misconfigured your web app to accept file uploads -- my ASP Upload
Accepter doesn't use a COM tool and runs just fine on IIS7...

Event Logs won't tell you anything. 32/64bit won't result in
"different" behavior due to file content, and Failed Request Tracing
will tell whether ISAPIs are involved at all.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

 

[Anthony Jones]

Event Logs won't tell you anything.

However, always check event logs, even when you sure they won't tell you
anything unless you happen to be called Neo and see the entire world around
you as a cascading set of green characters.

 

[Trevor Benedict]

What is the size of the Zip file ?

Regards,

Trevor Benedict
MCSD

 

[Kal]

Size is the obvious first place to look as that setting had to be tweaked in
IIS 6. Where would one set that in IIS 7?

 

[Kal]

Hello,

More information, this is very likely the file size problem. My users did
not provide good information in that very small zips (65K) work but larger
ones do not. I did not test for the cut-off, but 365K fails. And it is not
only zip files after all. A 700K doc file failed also.

So if I knew how to set the equivalent of what was
AspMaxRequestEntityAllowed this would probably get resolved very quickly.

Kal

 

[Anthony Jones]

Hello,

More information, this is very likely the file size problem. My users did
not provide good information in that very small zips (65K) work but larger
ones do not. I did not test for the cut-off, but 365K fails. And it is not
only zip files after all. A 700K doc file failed also.

So if I knew how to set the equivalent of what was
AspMaxRequestEntityAllowed this would probably get resolved very quickly.

In IIS7 IIS manager click in the web site and double click the ASP icon in
the features view. Expand Limits Properties and modify the Maximum
Requesting Entity Body Limit.

 

[Kal]

Anthony,
That did the trick. And it was so easy. You have no idea how many things I
tried that did not work.

I think there may be a second part though. One of the things I had done was
to change the setting in applicationhost.config from:
<sectionGroup name="system.webServer">
<section name="asp" overrideModeDefault="Deny" />
to
<section name="asp" overrideModeDefault="Allow" />

After I made your change and tested it, I changed the above to Deny just on
general principals of not fixing what was not broken. The website
immediately stopped working until I changed it back to Allow.

Thanks for your help.

Kal

 

[David Wang]

If you leave it as "Deny", then you can only change the setting inside
applicationHost.config -- which is certainly possible using <location>
tags, as the UI will illustrate.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

 

[David Wang]

However, always check event logs, even when you sure they won't tell you
anything unless you happen to be called Neo and see the entire world around
you as a cascading set of green characters.

Ok, then call me Neo.

In all seriousness, this is the rationale -- given that the user issue
is per-request (i.e. happens only on certain requests but not others),
if the issue is an IIS configuration, it CANNOT show up in the Event
Log. Why? Because that would then become a security vulnerability --
spamming the event log.

For IIS7, the fastest way to prove (or disprove) configuration is to
use Failed Request Tracing. Tracing tells you EVERYTHING that happened
on the request within IIS. One does not even need to ask the user for
configuration details -- the execution flow visible in Tracing gives
all necessary details. Given how flexible IIS7 can be configured,
Tracing is really the only consistent way to troubleshoot request-
bound IIS issues.

Of course, Tracing is effective when the failure is request-bound
within IIS. If the problem is elsewhere, yes, I agree that looging at
Event Log and HTTPErr log would be useful steps, along with network
sniffer for the traffic, as I've always advocated for troubleshooting.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//