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
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.
I have installed ITHIT webdav server engine. I tried using CalDev and Class1 server engine instances.
However, I was not successful with enabling content-range header.
When I am sending PUT with content-range header includes, the IIS server is responding with 501 not implemented.
Kindly help in resolving content-range header issue.
Typically CalDAV clients do not send PUT with Content-Range. The sample CalDAV implementation, generated by CalDAV/CardDAV Web Application wizard for Visual Studio does not implement resumable upload.
If you really need resumable upload in CalDAV/CardDAV server, you can modify the IContent.Write method implementation. This method provides necessary parameters to process segmented uploads. By default you can find the Write method in CalendarFile.cs file.
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?
I have to prevent a Cross-Site Scripting vulnerability from being sent in an HttpResponse from data in the HttpRequest header to pass a webapp assessment.
For example, HttpRequest Header:
GET /%22%20%73%54%79%4c%65%3d%58%3a%65%58%2f%2a%2a%2f%70%52%65%53%73%49%6f%4e%28% 61%6c%65%72%74%28%35%37%31%33%35%29%29%20%22 HTTP/1.1
HttpResponse Location Value:
/" sTyLe=X:eX/**/pReSsIoN(%?3e3ea140
My site is an ASP.Net website written in VB.Net running on Windows Server 2003 with IIS 6.0. What are my options? Do I have to use ISAPI filters in IIS?
Proper way to do this is to make sure your data in database (or whatever source you’re using) is clean and also to make sure you’re validating all user input on the server side.
Once you confirm your data is clean and that all input is being validated you should be safe.
Not sure if there are any built in ways in IIS.
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.