Well i have a http handler that is set up like this
<add name="DocumentHandler" verb="*" path="/LinkDocumentHandler/*" type="MyTestProject.LinkDocumentHandler, MyTestProject" />
(Remove name in IIS 6 and move it to the right section)
This works great in my VS webserver all requests that are going to the directory LinkDocumentHandler are handled by the handler..
Now when i come to IIS 6.0 this did not work so i googled a bit and found out that i have to define what file types IIS 6.0 will pass to asp.net well i can't predict all of them so that would not be so nice..
I tried to change /LinkDocumentHandler/* to /LinkDocumentHandler.aspx/* but that did not help..
So is there any way to force IIS 6.0 to pass all file requests with that sub dir to my http handler??
In IIS I added a Wildcard and unchecked "check if file exists" and it just worked (used the same dll that .aspx uses)!
This is very difficult to do in IIS 6, what you really need to do for this is write an ISAPI filter. Beyond that, IIS mappings are pretty much controlled by the file extension so it's very difficult to get it to pass all requests to asp.net.
There's a similar discussion here, where it appears the OP might have found a "partial" solution.
Related
I'm trying to get the 301 URL Tracker package for Umbraco to work to my likings.
My goal is to be able to map the old URLs (from another CMS) to the new Umbraco URLs. In my specific situation, the old site is PHP based and therefore use the .php file extension (http://example.net/test.php -> http://example.net/test/) - but it could be any non .aspx extension (asp, png and so on). The problem is that Umbraco is not handling request for .php files. It works perfectly for .aspx and directories (extensionless URLs).
I have tried various things for getting this to work. Before I go any further, I should note that the Application Pool is in integrated mode and .NET 4.0.
I kind of got it to work by defining a custom error in the web.config:
<customErrors defaultRedirect="not-exists.aspx" />
This triggers the handlers defined in NotFoundHandlers in the Umbraco config file 404handlers.config. But has the side effect of returning a 302 Found header, before the 301 URL Tracker kicks in and handles the 301 redirect. And this is just a big SEO "no no".
I then tried to explicitly create a HTTP handler module for .php files. I successfully got the System.Web.UI.PageHandlerFactory module to handle the request for the .php file. But this does not invoke any of the NotFoundHandlers in Umbraco.
As I understand the integrated pipeline in IIS 7, all the modules registered should try to handle the request (http://stackoverflow.com/questions/3765317/how-to-catch-non-aspx-files-with-a-http-module). But perhaps somebody can enlighten me on this subject?
Others are also experiencing the difficulties in getting this configuration to work: http://our.umbraco.org/projects/developer-tools/301-moved-permanently/feedback/7271-when-the-old-pages-are-not-from-umbraco
What am I missing in getting Umbraco to handle request for non .aspx files in integrated pipeline mode?
If you are already running under Integrated Pipeline mode then the included UrlRewriting.net module should pick up requests automatically.
Simply add:
<add name="phptoaspx"
virtualUrl="^~/(.*).php"
rewriteUrlParameter="ExcludeFromClientQueryString"
destinationUrl="/$1.aspx"
ignoreCase="true" />
to your /config/UrlRewriting.config file, and all should be well.
P.S. You should not be using a customError handler to handle SEO 301/302'ing content. This can be a massive headache in terms of maintainability - please trust me on this, I tried this once when I was a junior .NET dev!
I am not familiar with Umbraco, but believe this is what you are looking for http://blogs.iis.net/ruslany/archive/2008/09/30/wildcard-script-mapping-and-iis-7-integrated-pipeline.aspx
Of course you'll have to add your own rewrite rules... so this only gets you half way.
We run a link redirection service which can handle links thrown at it in various formats. One of these formats is to append the destination URL to the end of the link, for example
http://url.fwd/abcd/http://www.mydomain.com/page.aspx
This was working on a Windows Server 2003 / IIS6 box for the last two years, but now we're trying to move to a Windows Server 2008 / IIS7 setup and its not working anymore.
I've read about the problem with colons in the URL but it doesn't affect pages not ending in '.aspx'. For instance,
http://url.fwd/abcd/http://www.mydomain.com/page.php
would redirect fine.
http://url.fwd/abcd/http//www.mydomain.com/page.aspx
also works fine (note the lack of a second colon). Despite being the wrong URL, it does get handled by our URL forwarding system, which uses a custom 404 page. On the old system, we had a similar problem, so a method was written in Global.asax > Application_Error specifically to handle the '.aspx' case, and it worked fine.
On our new server, the Application_Error never gets thrown in Global.asax. Instead, I get a System.NotSupportedException - "The given path's format is not supported". This System.NotSupportedException is the exact case we handle in the Global.asax page, so it's definitely not being fired.
I've changed the registry keys indicated in several forum posts,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET VerificationCompatibility=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP|Parameters AllowRestrictedChars=1
I've tried changing the Handler Mappings settings for .aspx.
I've tried setting the App pool to use classic mode instead of integrated, but this causes a completely different error where static content such as images and CSS do not display at all. I've checked that static content is enabled in the windows features, and it is.
Under classic mode, the '.aspx' request throws two Bad Request errors with absolutely no information whatsoever. The code of the error page I get is literally
Bad Request<html><body>Bad Request</body></html>
UPDATE: I've changed the static file Handler Mapping to the form found in this page
http://improve.dk/blog/2006/12/11/making-url-rewriting-on-iis7-work-like-iis6
However, as the author rightly points out, this is a hack and not the correct way of doing things under IIS7. It also only fixes the static file problem in classic mode. '.aspx' pages still throw an error under classic mode.
Any thoughts or input would be greatly appreciated at this point.
IIS 7 Solution
The easy solution in IIS 7 is to add a setting in your web.config file to tell IIS to process all requests through your Global.asax events. Just add or change this section in your web.config to enable requests:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
In my case, I was publish my site in production and I miss copy to server App_global.asax.compiled file. For this reason was not fire the Events inside Global.asax.
Hope anyelse help this tips, I lost 8 hours seeking.
Request.RawUrl always returns the /default.aspx variant. I did not find any way at all to differentiate between these urls. Does anybody know how to do that?
Environment is .NET 3.5SP1 on IIS 7.
I actually had to combat this same problem when designing my URL Rewriter. It has to do with the processes that occur before you can even access the URL's. To get around this you have to make sure that in IIS 7 the default page handling is turned off. Because if there is no default page handling it is not going to go through the extra step of trying to map it to the drive, so you will be the exact URL requested. But this may or may not be an option depending on if you are using System.Web.Routing or not.
To turn off the default page handling you need to do the following:
Go to your site in IIS
Go to Default Document
Click Disable in the top right corner.
Or you can add the following to your web.config:
<system.webServer>
<!-- ... other tags here ... -->
<defaultDocument enabled="false" />
</system.webServer>
After you do this the default document will be no longer added to your URL. However be warned that since this is no longer active you cannot rely on default.aspx actually mapping to your directories, you will have to handle this manually or use something like System.Web.Routing to handle this functionality.
To accomplish the same in IIS 6 you need to turn on wildcards:
The following instructions apply for IIS 6.
Open IIS and right-click on the website and select 'properties'.
Click the 'Configuration' button under Application Settings section
Click the 'Insert...' button to create a new wildcard mapping
Set the executable textbox to aspnet_isapi.dll file location.
for .net 2.0, 3.0, 3.5: C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
Make sure the checkbox 'Verify that file exists' is not checked.
Press 'OK' to confirm and close all the windows.
NOTE: by the way all the source is available on the site I linked above incase you were curious how I was doing things.
I set up iis to handle .exe with "asp.net 2.0"s isapi filter to enable dynamic url replacement.
For this I setup the extension in iis and added the following line to web.config. Works fine so far.
<add path="*.exe" verb="*" type="System.Web.StaticFileHandler" />
the problem is that form that point w3wp process has several handles on these files. Most likely because someone is downloading them at the moment.
Is there a way to tell iis/asp.net not to put a exclusive handle on the file? I want to replace them even if the site is running. This works as long as asp.net does not handle these files.
I don't think there is a way to do this. You are telling IIS to handle this filetype, so the server is assuming a certain exclusivity. This behavior is intended IMO, because it prevents corrupted files in production environment.
Maybe it helps to limit the requests to some selected HTTP verbs (POST/GET), but i don't see any other options.
And the other question is: why do you want to replace a file, that is currently downloaded by a user? It will corrupt his download, forcing him to start all over again.
Platform: IIS 6, ASP.Net 2.0 (.Net 3.5), Server 2003.
I'm building an application that accepts files from a user, processes them, and returns a result. The file is uploaded using HTTP POST to an ASP.Net web form. The application is expecting some large files (hundreds of MB).
I'm using SWFUpload to accomplish the upload with a nice progress bar, but that's not contributing to the issue, because when I bypass it using a standard HTML form pointing at my upload accepter page, I get the exact same error. When using the progress bar, the upload continues to 100%, then fails. With a standard form, the behavior appears to be the same.
I'm having a problem right now uploading a file that's about 150MB. I've changed every settings I can find, but still no luck.
Here's a summary of what I've changed so far:
In Web.config:
Added this inside system.web:
<httpRuntime executionTimeout="3600" maxRequestLength="1536000"/>
In machine.config:
Inside system.web, changed:
<processModel autoConfig="true" />
to:
<processModel autoConfig="true" responseDeadlockInterval="00:30:00" responseRestartDeadlockInterval="00:30:00" />
and in MetaBase.xml:
Changed:
AspMaxRequestEntityAllowed="204800"
to:
AspMaxRequestEntityAllowed="200000000"
When the upload fails, I get a 404 error from IIS. My web form does not begin processing, or at least, it doesn't make it to the Page_Load event. I threw an exception at the beginning of that handler, and it doesn't execute at all on large files.
Everything works fine with smaller files (I've tested up to about 5.5MB). I'm not exactly sure what file size is the limit, but I know that my limit needs to be higher than 150MB, since this is not the largest file that the client will need to upload.
Can anyone help?
Urlscan was active on all websites, and has it's own request entity length limit. I wasn't aware that Urlscan was running on our server because it was a global ISAPI filter, not running on my individual website.
Note: to locate global ISAPI filters, right click on the Web Sites folder in IIS Admin and click Properties, then on the ISAPI Filters tab.
(A note for googlers):
For IIS7 add below to web.config (I added above <system.serviceModel>):
<system.webServer>
<security>
<requestFiltering><requestLimits maxAllowedContentLength="262144000" /></requestFiltering> <!-- maxAllowedContentLength is in bytes. Defaults to 30,000,000 -->
</security>
</system.webServer>
When we ran into this issue we had to increase the buffer size limit according to this KB article:
http://support.microsoft.com/kb/944886/en-us
I know this mentions ASP, but I believe it worked for ASP.NET as well.
Edit: Here is a link that might be more relevant to your issue and provide other options:
http://weblogs.asp.net/jgalloway/archive/2008/01/08/large-file-uploads-in-asp-net.aspx
404 and missing Page_Load: IIS can only process the request once the complete POST is on the server. Therefore, if the POST fails (due to its size), it cannot fire the page's events.
You might try NeatUpload http://www.brettle.com/neatupload.
From the Manual: "By default, NeatUpload does not directly limit the size of uploads."
You can also try Velodoc XP Edition which has several advantages over NeatUpload including the fact that it uses ASP.NET Ajax extensions. See also the Velodoc web site for more information.
You say:
But 1536000 is only 1.5MB?