I'm attempting to configure a webdav server example application (https://sourceforge.net/projects/webdav/) to run on IIS6 (Win2003 Server). The application runs correctly on my dev machine (Win7, IIS7.5).
When I attempt to map a drive to the DAV share, several requests are issued, including one OPTIONS request and two PROPFIND requests.
In Fiddler, I see that these are transmitted correctly. However, the response is always the content of the default page on the site. If I look at the IIS logs, the requests are logged as GETs instead of OPTIONS or PROPFIND.
UrlScan is disabled, but I went ahead and added OPTIONS and PROPFIND to the list of allowed verbs (since I'm running out of ideas).
Help.
Solved.
Turns out that URLScan wasn't disabled, though it was not listed in the ISAPI filter list in IIS Manager. Just for kicks I renamed the URLScan.ini file, which resulted in an exception when any site on the server was hit.
Rather than removing URLScan completely (following the Prime Directive), I modified the denyVerbs and DenyHeaders sections to allow all of the DAV stuff.
I'll accept an answer from the first person to provide a clear explanation of what security problems this may introduce if put in production.
Related
I have an ashx handler, and the response is not gzipped. The content-encoding received by the client is empty.
The IIS settings for the site have static and dynamic compression enabled.
Research of similar problems shows some people have an httpCompression node in the web server node of IIS configuration editor. I do not have such a node. I have a url compression node, where I have set everything to true. Perhaps that is IIS version dependent. The op system is Windows Server 2008 R2.
I am about to try to "force" compression using the filter property and the GZipstream class (credit to Rick Strahl's blog). If anyone can tell my why IIS is not "auto compressing" or can point to any gotchas in my workaround I would be grateful.
Update: attaching GzipStream to the response filter reduced the content length by half as seen by the client, which seems to indicate the "manual" compression is doing something.
I am aware this was previously asked here:
.ashx handler not getting gzip compressed despite IIS Config setting
However, the previous question did not receive any answers, so I am asking the question again.
Please check if you are adding Accept-Encoding", "gzip" in request headers while making HTTP request.
What would cause a site to try an go to an https url?
We have sitecore set up to redirect non www URLs to www pre-pended URLs. Example: joesrx.com resolves to www.joesrx.com through the Sitecore URLResolver.
What we are seeing is that if you type joesrx.com, it tries to go to https://joesrx.com before it hits the Sitecore server. Since there are no certificates on this server and https is not utilized we get a 404.
Is there something in IIS that is misconfigured? Proxy teams says it is not in their setting and network team says all of the DNS entries are correct.
As a general rule for debugging these sorts of problems, try to imagine all the elements between you and the application and then use a simple divide and conquer approach. You can also test behavior on individual levels of the path between you and the actual application.
In this case for example (from you to application code):
User
Browser
browser may do caching of redirects. Try a different browser / try incognito mode / clear cache
Browser Extensions/Settings
any extensions which make it so the browser always tries to access website(s) via https? Try with extension disabled / another browser
Proxies/Firewalls
any Proxies/Firewalls on your end which may modify requests? Can you try to access the site bypassing any proxies/firewalls, maybe from a different network connection?
Network
Web Server
Web Server Configuration / Pipelines / Resolvers / Filters / Etc.
.htaccess / IIS config / nginx config / servlet filters / (lots of options depending on your framework). Check the server
Actual application code
well.. check the code.
Example of divide and conquer, choosing the Network mid-point: Try accessing the URL with wget/curl from command-line, curl -i will also show you the headers received from the server. If you find a "Location: .." header it's clear that the server is sending a redirect. So now you only have to check Web Server / framework configuration and actual application code.
There are a few things I would check first:
Do you have rewrite rules in your web.config? They may be pattern-matching on www. and redirecting in order to enforce SSL
Do you have code in your pipelines that is attempting to enforce SSL for specific paths? The code here may not be checking the URL correctly.
In IIS, did you bind the 'www' host name to your IIS site? Or is it falling through to another site that has SSL enforced?
In case the other answers don't help, check for HTST headers such as "Strict-Transport-Security: max-age=31536000".
This HTTP header tells browsers to use only SSL for future requests (among other things).
For more info check out:
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
I have a Windows 2008 Server running the default IIS 7.0. I have an http handler where GET, POST, and PUT are working fine, but whenever I issue a DELETE request, there is nothing coming back from the server at all.
I'm using Fiddler to issue the request (which works great on my development Windows 7 machine). I have disabled WebDav, etc., which by the way should have given me some kind of error response anyway. In this case there's nothing. I've tried to enable tracing on the server and don't see anything there either.
I have tried to issue the DELETE web requests on other pages on the server as well, including non-existing ones, but there's never any respone. Maybe something on the server is "eating" the request before it gets to IIS?
To test this last question, I installed Fiddler on the server itself and posted the DELETE request from within the server. This actually worked!!! So, what's stopping the external request then?
We have a number of existing clients that point to urls like:
http://sub1.site.com/images/image1.jpg
/images is a virutal directory that points to a directory that actually contains image1.jpg on that server.
We're moving all of the files out of this directory and onto a separate server that will not run this same application.
The file will now only be available at:
http://sub2.site.com/image1.jpg
What is the best way to make it so clients requesting
http://sub1.site.com/images/image1.jpg will get the content that now resides at http://sub2.site.com/image1.jpg?
A few requirements:
We need the actual content to be returned through that url - not a 302 response.
We cannot modify the IIS server configuration - only the web.config for the site
Again, we're running asp.net 3.5
Thanks.
Not totally sure this would work, but you could setup URL Routing on the old site so all requests are sent to a handler and within that handler you could do a web request to get the file from it's new location.
I use a variation of the process to map image URLs to different locations and my handler does some database queries to get the mapped relationship and provide the correct image. I don't see why you could do a web request to get the image.
Since you are using IIS7, you can use the built in URL rewrite module.
You would want an inbound and an outbound rule to change \images\image1.jpg to \image1.jpg
It can get pretty involved, but this should be rather simple.
Assuming you can add handlers to your site (as in add a DLL to your /bin directory in the site) and with the restriction that you can't send 302 responses for better performance, then alternatively you could write a custom handler to grab all requests that match that URL pattern, do the web request for the sub2.site image from the original site via web client code, then serve it back out of the original site, sub1.site.com.
See How To Create an ASP.NET HTTP Handler by Using Visual C# .NET for the very basics of creating and setting up a custom handler. Then use the HttpWebRequest to make the request of sub2.site.com, as in the guide A Deeper Look at Performing HTTP Requests in an ASP.NET Page. Plus a little other code to handle errors, timeouts, passing the image through with as little processing and memory usage as possible, etc.
Depending on the response time/lag between the two servers, this may be slow, but it would fit all your requirements. But if the point of moving the images to site 2 was for performance (CPU or memory) or bandwidth limitations, then this solution would nullify any gains — and would actually make things worse. But if they were moved for other business or technical reasons though, then this solution might be helpful still.
If you have other control over the server or anything upstream from the server, you could use mod_proxy (or similar Windows/IIS tool) to intercept those URLs and forward them to another server and respond back with the real request. Depending on your network configuration and available servers, this could be the simplest, best performing solution.
Can IIS be configure to forward request to another web server? on serverfault has a quick process and link for an IIS 7.5 solution.
I suspect the answer is no (or at least, not in an intelligent manner), but felt like asking.
Is it possible in an asp.net HttpModule to determine the page that is going to be returned to the user, taking default page settings of IIS into account (without hardcoding them outside of IIS). For example, if a user requests http://www.example.org/bar/, the real page might be http://www.example.org/bar/index.html -- but could just as easily be http://www.example.org/bar/foot.html , depending on the user's IIS settings.
You're correct: in cases where there was no file.ext available in the requested URL, the IIS settings would have to be available in order to determine the actual page that was returned.
Given that the module has to live on the IIS server, I think you could get the list of default pages configured in IIS by connecting via WMI. You'd then have to get the list of files in the requested folder to figure out which of the default pages was actually returned.