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.
Related
In the past I have dealt with security issues related to Default Service Banners/Verbose Headers/Information Leakage via HttpResponse Headers. These issues are quite common, and usually look something like this for an Asp.Net - IIS Server.
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
These types of issues are very common, and usually quite trivial to deal with, typically a web.config update or an URLRewrite rule to remove the verbose headers.
However, one issue I stumbled upon lately, is when the Server encounters an error, these headers are not removed. For example a 404 (not found) error will still have these headers appended on. In fact most error responses are not able to properly remove the information leakage headers. I did some searching and found out this issue is not very well documented, in fact it has never come up in one of our Pen-Tests specifically.
I am curious if any other developers have dealt with this issue, specifically information leakage in HttpResponse Headers when the response code is an Error. If so, how did you fix it. I am using Microsoft, Asp.Net, IIS technologies, but still curious if other technologies/servers have this issue.
Thanks to Cody (Security Champion) response.
reviving an old thread here, but we have had many applications to mitigate this problem for. we've actually done it at the load balancer level, so that all responses, error or otherwise, are treated the same
we're doing that with an iRule for F5 - iRules Home
https://clouddocs.f5.com/api/irules/
the irule has an array of blacklisted header names, and just removes those on every response
if you're trying to accomplish the same thing within AWS or some other managed load balancing mechanism, unfortunately i'm not sure how you would go about doing that
I'm trying to get Dynamic Compression on IIS 8.5 to work (particularly with JSON). I'm using Windows Server 2012, IIS 8.5 and a very simple ASP.NET MVC site returning an ActionResult in the form of JSON. Firstly I have done all the usual steps, enabling Dynamic Compression in IIS at the server and site level, edited my applicationHost.config with the correct MIME types, frequency etc.
I have enabled FailedRequestTrace logging, and what is strange is that my request is reporting a successful compression, however Chrome/Fiddlr disagree:
And the response in Trace logging contains the header "Content-Encoding: gzip":
But the response in Chrome/IE/Fiddlr does not contain that header nor is the response compressed, it would appear that something else is interfering! Please help!
If the server is serving the response zipped (use WireShark to determine this) but you are seeing the response deflated in the browser it's likely to be your antivirus unzipping before the content gets to your browser
WireShark
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.
How do I compress the output data from a web service (web method). The output is XmlDocument type.
Here is the code.
[WebMethod]
public XmlDocument GetPersonalInfo(int CustomerID)
{
XmlDocument doc = new XmlDocument();
doc.LoadXml(new CustomersXML().GetPersonalInfo(CustomerID));
return doc;
}
How do I Gzip this response. Please remember that it is not a page (HTTP call) its a web service that is being called from a Flex client.
Thanks
This answer references an ancient article explaining how to implement this programmatically using SharpZipLib.
Another answer demonstrates use of the System.IO.Compression classes which could be substituted for SharpZipLib.
Rick Strahl put together an article reviewing potential issues to be aware of when implementing compression which do not appear to be addressed in the examples provided above. He also links to an article providing more details on usage of IIS7 built-in compression.
go to your iis or whatever config file, and add the following line in the appropriate place:
<add mimeType="application/json" enabled="true" />
i've had the same problem - my IIS was able to GZIP any http response, except for json responses (which where needed a gzip compression the most on my app).
hope that helps
Update:
the application host config file should be located here: %windir%\System32\inetsrv\config
I don't have time to look for code but there is a namespace System.IO.Compression that has several classes for both Gzip and Deflation-based compression schemes. Gzip is probably a safer bet for cross-language communication as I'm not certain as to how widespread deflation compression is.
However, you shouldn't have any trouble in the communication so long as there is a header with the SOAP packet telling the client server to decompress the stream.
Note: Double check your server settings before doing this though, as some hosts have Gzip turned on by default and you don't want to do it twice.
This is nothing to do with .NET.
GZIP is an HTTP feature in Web Server - provided the client supports it which generally notifies the server by sending GZIP in the ACCEPT headers when sending the request.
You need to set it up in IIS. Depending on the version, it can be different. In IIS 7 it is very easy, just a flag to set. See here.
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.