How to get x-server variable back in IIS 7.x - iis

I'm not sure if this was a change in IIS 7 or if someone before me actively removed X-Server from the HTTP response headers but I need to be able to tell which server in the farm served the current page. I don't see X-Server in the custom variables section of IIS but I'm not sure if it was a custom variable in the first place or if it's in the defaults and it's been disabled via web.config. How do I get my headers back?

You can use custom headers (http://www.iis.net/ConfigReference/system.webServer/httpProtocol/customHeaders) to add any header you like.

Related

Server Header Information Showing up in IIS

I am facing an issue where server header information is showing up in IIS. I know by using URL rewrite module and creating outbound rule will resolve the issue. Problem here is when i am checking individual severs i am seeing server header information as Server:-Microsoft-IIS/7.5. and when i am checking LB URL i am seeing server:- IA Web server. not sure from where this text is coming up.I checked the web.config file but the entry for witting own server information is not present in an tag. Also one more information i have akamai implemented after the web servers. Could some one help in this context.
This is added by IIS Server. Adding outbound URL-Rewrite rule is the best way to go as adding a custom HTTPModule to remove headers or through global.asax.cs as explained in this answer won't work for static files.
See detailed blog here - https://blogs.msdn.microsoft.com/varunm/2013/04/23/remove-unwanted-http-response-headers/

What is globally adding an "x-frame-options: deny" header?

I have a client who uses ColdFusion 10 and IIS 7.5 on Win 2k3 R2. The ColdFusion admin uses frames. When I log into the CF admin I'm seeing a blank white screen in Chrome and in IE I am seeing a message telling me this:
This content cannot be displayed in a frame
To help protect the security of information you enter into this website, the publisher of this content does not allow it to be displayed in a frame.
I see a few of this message (1 for each frame) in the chrome dev console:
Refused to display 'http://localhost/CFIDE/Administrator/navserver.cfm' in a frame because it set 'X-Frame-Options' to 'DENY'.
Looking at the response headers in Chrome, I can see that this is set to DENY.
I can't figure out where this is coming from. All of the sites on this server now are outputting this header. I never explicitly configured anything to output this header. I know CF wouldn't have done so in a patch because it would break its own admin interface.
IIS's root server-wide configuration HTTP Response Headers doesn't have a X-Frame-Options set and neither do any of the configured websites.
If I explicitly add an X-Frame-Options header and set it to sameorigin I see both headers (deny and sameorigin).
Is there perhaps some software the client's security team might have installed that would be injecting this header?
I'm accessing the site on localhost so I can't imagine that it's a network device causing the problem. It must be on the server itself, right?
Any ideas?
This could be set within ColdFusion, assuming it's been locked down. Look in
(instancename)/wwwroot/WEB-INF/web.xml for the rules around clickjack. Might look something like this:
<filter-mapping>
<filter-name>CFClickJackFilterDeny</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Another way to test to see if this is being caused by IIS is to set up a frame sample with straight HTML pages and if it works the block is at the ColdFusion level. If straight HTML does not work then it is happening at IIS or some other server location.
In IIS, HTTP Response Headers can be set server-wide (affecting all sites) and/or site-wide (affecting only the current site).
Reading your question again, I see I may not have helped you. Good luck.

GET request to IIS returns Microsoft-HttpApi/2.0

I've got 6 identical machines running IIS and Apache. Today one of them decided to just stop serving requests. I can access all of the webapps when I try from localhost/resource but when I try from url/resource I get a 404. I did a Get request against the machine that isn't working and I get this back:
Server: Microsoft-HTTPAPI/2.0
Connection: close
Compared to a working server:
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Content-Type: text/html
Tried searching for this problem but came up with nothing, anyone got any idea's?
Windows has an HTTP service that manages calls to IIS and other HTTP enabled services on a windows machine. Either you need to configure it to handle your calls, or, in the case of WAMP or similar non-IIS-web-server-on-windows scenarios you may just need to turn it off.
When you see "Microsoft-HttpApi/2.0" returning error, such as 400 "bad URL" or "bad header", etc. the problem is most likely because the HTTP.sys service is intercepting your http request and terminating it because it does not meet with the minimum validation rules that are configured.
This configuration is found in the registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters. In my case, it was choking because I had a RESTful call that had a 400 character segment in the url which was 160 characters more than the default value of 260, so I
added the registry parameter UrlSegmentMaxLength with a DWORD value of 512,
stopped the service using net stop http
started the service using net start http
I've run into these issues before and it is easy to troubleshoot but there is very little on the web that addresses it.
Try these links
"the underlying problem is that the client has sent a request to IIS that breaks one or more rules that HTTP.sys is enforcing"
enabling logging on HTTP.sys is described here
a list of the HTTP.sys parameters that you can control in the registry is found here.
A bit late, so put here for posterity ;-)
After trying all sorts of solutions found on the web, I almost gave up, but found this little nugget.
If the response's Server header returns Microsoft-HttpApi/2.0, it means that the HTTP.sys is being called, not IIS.
As a result, a lot of the workarounds will not work (URLScan, etc).
This worked however:
Open regedit
Navigate HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\
If DisableServerHeader doesn't exist, create it (DWORD 32bit) and give it a value of 2. If it does exist, and the value isn't 2, set it to 2.
Finally, restart the service by calling net stop http then net start http
src: WS/WCF: Remove Server Header
Set below registry flag to: 2
HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\DisableServerHeader
Setting this to 2 will ensure that self host WCF services no longer sends the SERVER header and thus ensure we are security compliant.
Please note that this disables ALL server headers.
The default value of 0 enables the header, and the value of 1 disables server header from DRIVER (http.sys), but app can still have headers.
For me I had to restart the server for the changes to take effect.
Hope this helps someone
I was working on our web app on a client's site and ran into an issue where the site root pages loaded, but the reports folder always returned a 404 for files that existed in the folder. The 404 page showed the .Net version of 2 when the application was set to 4, and a test of a non-existent page in the root returned a 404 page showing .Net 4.
I tried just http://localhost/reports and got back a Microsoft Reporting Services page. Not part of my application.
Be sure to check just the default document of the folder when a unexpected 404 comes up and the file exists.
This question and series of replies helped me get to the bottom of the related issue I was having. My issue centered around using just a subdomain to go to our server (e.g. typing "www/somepath" into the browser while on our corporate network), which had worked in the past on an older server, but no longer worked when the system was upgraded to a new server. I saw the unexpected Microsoft-HttpApi/2.0 string in the header when using the Chrome Devtools to inspect the Network traffic.
My HTTP.sys process was already logging, so I could verify that my traffic was going to that service and returning 404 NotFound status codes.
My resolution was to add a binding to the IIS site for the subdomain, making IIS respond instead of the HTTP.sys process, as described in this server fault article - https://serverfault.com/questions/479274/why-is-microsoft-httpapi-returning-404-to-my-network-switch
In my case, running Windows 10 Pro, it was the Windows MultiPoint Service.
By executing:
net stop wms
Port 80 was released.

IIS V6 autoblocking ip

the linux-guy here has a question about IIS v6.
The case is, that i have a site running, when i do some specific tasks on this site ( Like deleting a specific item, three times in a row) the site will break, and a completely blank page will appear. Checking the response headers, i noticed that the server sends a "403 Forbidden: IP address of the client has been rejected."
Through a proxy, i can connect just fine.
Checking the site-options in the IIS manager, shows me that my IP is not blocked globally, its something thats just happening.
Where can i check for this? It happens automatically and the block ends after about 8-12 minutes, every time?
best regards.
Jonas
do you have access to IIS?
i assume blocking occure on web site side (inside ASP code), not in IIS.
please check IIS console, and make sure that there are no blocked IP's. If it's true, you should find database/table or some config file, where stored all blocked IP's. After that, you should get able to find ASP code, which is responsable for blocking....
you also could try make quick search inside all ASP pages for text like: "REMOTE_ADDR" and ".ServerVariables"

Vary header when content is not gzip:ed on IIS 7 as origin for CDN

I'm trying to set up my IIS server as an origin server for a CDN. I have solved some issues already for example that IIS doesn't give gziped content to proxies (if they have the via header) and also that frequentHitThreshold problem.
My CDN supplier pointed out that another problem with IIS is that it doesn't return a "Vary" header if the client doesn't request the content gziped. According to them the problem is that if for some reason the first client that request the content doesn't want the content gziped the CDN then doesn't request a new version of the file since the Vary header doesn't indicate that it should return two different files depending on "Accept-Encoding".
My only solution so far is to add "Vary: Accept-Encoding" as a custom header but since IIS automatically add this vary header when gziped is requested so i end up with multiple values like "Vary: Accept-Encoding, Accept-Encoding".
Anyone have any solution to this? Or can confirm that it's a real issue.
This is a real issue. IIS gzip module overwrites existing Vary headers. Please vote on this MS Connect issue. Related article here.
This issue is now addressed by an official patch to IIS. To download and further info, visit http://support.microsoft.com/kb/2877816
Erez Benari, IIS PM

Resources