When trying to access /Glimpse.axd after I've published to IIS (7.5), I'm now receiving a 403 Forbidden response. Is there a setting in IIS that disables access to .axd files? Or is this something else entirely?
This is usually due to the fact that your source IP Address is not allowed in the web.config section for Glimpse. I just ran in to this issue yesterday.
Look for this in your web.config file, it can go anywhere in the web.config file.
<glimpse enabled="true">
<ipAddresses>
<!-- List of IP addresses allowed to get Glimpse data. Optional. localhost (IPv4 &IPv6) by default -->
<add address="x.x.x.x"/> <!--The ip of your machine -->
<add address="::1"/>
</ipAddresses>
</glimpse>
I got an error like this when trying to access http://leniel-pc:8083/glimpse.axd:
403 Forbidden
Ensure 'aa90::edad:55a5:7777:cd2c%11' is configured for
Glimpse access.
After doing this:
<glimpse enabled="true">
<ipAddresses>
<!-- List of IP addresses allowed to get Glimpse data. -->
<!--The ip of your machine -->
<add address="aa90::edad:55a5:7777:cd2c%11"/>
</ipAddresses>
</glimpse>
Problem solved! :D
Related
I have website created under IIS 8.0 in Windows 2012. An URL rewrite with ARR has created under this site which points to a linux machine (Basically to a webservice deployed in Tomcat) and through IIS there will be "GET" request where the URL is exceeding more than 5000 characters along with query string. When the URL is hit through program or in browser, I see IIS throws "Bad Request" with Status code as 400 and no Substatus code. The same works when it is directly hit to the webservice (for tomcat Linux). I suspected the issue is because of the excess characters in the url, because when I try decreasing the url length to 3500 characters which works without any error. Below are the configuration and settings that I have tried in IIS web.config and as well as http.sys registry, but nothing seems to be work.
<configuration>
<system.webServer>
<security>
<requestFiltering allowDoubleEscaping="true">
<requestLimits maxAllowedContentLength="4294967295" maxUrl="10999" maxQueryString="2097151">
<headerLimits>
<add header="Content-Type" sizeLimit="100000000" />
</headerLimits>
</requestLimits>
</requestFiltering>
</security>
<urlCompression doDynamicCompression="false" />
</system.webServer>
<system.web>
<httpRuntime maxRequestLength="8192" maxUrlLength="8192" maxQueryStringLength="8192" requestPathInvalidCharacters="" />
</system.web>
</configuration>
http.sys Registry Settings
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength - DWORD - 65534
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes - DWORD - 16777216
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\UrlSegmentMaxCount - DWORD - 16383
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\UrlSegmentMaxLength - DWORD - 32766
I have rebooted the Windows server after every above settings and configurations was done.
These settings and configuration are honored by IIS without url rewrite. If I try other url with length of 5000 characters for the same website its works without any error. This is appearing only for the url that has fallen under URL rewrite config. Is there any specific configurations that need to be done with respect to URL length in ARR apart from the above mentioned? Please suggest and help.
Thanks in Advance.
Answering to my question.
The issue was on the Linux Tomcat side not on IIS, the catalina.out logs was stated as below
INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Request header is too large
I added the configuration of maxHttpHeaderSize="65536" in server.xml of tomcat/conf. After modifying this, the issue was resolved.
I am trying to send a delete request to my Web API service via Fiddler and am getting back a 405 "Method not allowed" error.
I have read extensively about removing the "WebDAV" module in web.config and similar suggestions (WebDAV is not enabled in my applicationhost.config anyway), but nothing I have tried has worked.
My service is currently running on IIS Express 10 (launching from Visual Studio). I do have this in my web.config file:
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler"
preCondition="integratedMode,runtimeVersionv4.0"/>
I would have thought the verb="*" piece would have allowed DELETE, but it does not seem to work.
One other note - when I inspect the response in Fiddler, under the Security heading it says: Allow: GET, POST.
I am not sure where that "Allow" parameter is being set (I am new to Web API).
Any help would be greatly appreciated. Please let me know what other information you need from me and I will add it.
Thank you!
Just reproduced this by creating a new webapi project [targeting .net framework 4.7.1]
Through Fiddler, I can hit the DELETE endpoint without any changes to web.config.
Please make sure to use correct endpoint including the id parameter.
e.g http:localhost:xxxx/api/values/id // please include the id and xxxx is port number.
If http:localhost:xxxx/api/values is used without id , I get the same result 405 Method Not Allowed
Hope this helps.
You can modify the IIS Express applicationHost.config in the %userprofile%\documents\IISExpress\config folder. To enable PUT and DELETE for extensionless Urls scroll down to the bottom of the IIS Express applicationHost.config file and look for a handler entry that starts with: <add name="ExtensionlessUrl-Integrated-4.0".... In the "verb" attribute add PUT and DELETE so the "verb" attribute looks like: verb="GET,HEAD,POST,DEBUG,PUT,DELETE"
Update your web config like this
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule"/> <!-- ADD THIS -->
</modules>
Perhaps I'm missing something by not wording my Google searches correctly, but I've run into an issue with IIS 8.5 and caching. I have a server set up that by all standards should be serving only static files. Obviously, when a file is changed, the new file should be served up. The issue is that even after a server restart, setting files to immediately expire, didsabling caching, disabling compression, and turning off any other caching feature, the old file with its old timestamp is still being served.
I have the following settings:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering allowHighBitCharacters="false">
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
</verbs>
</requestFiltering>
</security>
<caching enabled="false" enableKernelCache="false" />
<urlCompression doStaticCompression="false" />
</system.webServer>
<location path="" overrideMode="Deny">
<system.webServer>
</system.webServer>
</location>
<location path="" overrideMode="Allow">
<system.webServer>
</system.webServer>
</location>
</configuration>
The folder in which the files are located has read only permissions. The interesing fact is that if I go to mydomain.com, the old version shows up, but going to newmydomain.com loads the new file (even though they both point to the same IP address).
An HTTP client can use the old version of a file if the cache control header(s) sent with the response indicated that the content would not change for a given period of time. It does not matter if the content changed on the server or not.
For example, if the file is sent with the header:
Cache-Control: Max-age=86400
then for 24 hours the client can use the file without contacting the server. If the file changes on the server, the client won't know that the file changed because it won't even make a request to the server.
You can add the must-revalidate cache control attribute to force the client to always make a server request.
As noted in my reply to storsoc, our issue was that our load balancer, an F5 server, was trying offload as much as possible from our web servers by caching our site. See K13255: Displaying and deleting HTTP cache entries from the command line (11.x and later) for how to forcefully remove cached entries.
I ran into a weird issue when migrating a site on to a new web server.
I have some custom handlers written and defined in my web.config:
<add name="CalendarHandler" verb="*" path="/api/Calendar" type="CalendarHandler" />
If I do not put a file extension on the path like "/api/Calendar.css" the response that comes back is a redirect loop. If I put any extension on the path it will return the correct response. Removing the extension causes a re-direct error.
The path="/api/Calendar" works just fine the old server. I have moved the site from IIS 7.5 WIN 2008 R2 to IIS 8.5 WIN 2012. I am not sure what setting I am missing in IIS. I have made sure all the handler mappings are the same and I have tried installing URL Rewrite. No luck.
I changed the path to
<add name="CalendarHandler" verb="*" path="/api/Calendar/" type="CalendarHandler" />
and it worked. For some reason IIS 8.5 did not like 'path="/api/Calendar"' the missing '/' caused the redirect loop.
This is both information to those experiencing the issue and a question.
edit: The question is why does dropping "www." from the URL cause this error when a website running at the same address can be referenced without "www.".
I recently reproduced this problem using a trivial WCF service (the one from endpoint.tv) after resolving the usual config issues one faces moving a service from local IIS to shared hosting.
The problem was the following response (from fiddler) upon checking the url in browser. In searching the web for posts on the topic I found a number of unresolved issues pointing to the same problem in addition to the posts where the usual shared hosting config issues fix them up.
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Tue, 17 Aug 2010 00:27:52 GMT
Content-Length: 0
In Safari/Chrome this manifests as a blank page.
In IE you get "The webpage cannot be found".
In FF you get "XML Parsing Error: no element found Location: http://................ Line Number 1, Column 1:" (which I saw in numerous unresolved posts on the web - feel free to backlink a possible solution)
In Opera you get "Invalid Address"
I was scratching my head regarding this for a while, then I thought to try putting in the "www." which I was previously omitting from my url for no particular reason.
Problem solved.
I can now see the normal output in the browser and interact with the service via WCF Test Client.
So the question is:
Why does this make a difference to the hosted WCF service when I know it does not make a difference for browsing to the website hosted at the same address? With or without the "www." I can browse to the website at the same domain, hosted on the same account.
So far I've tested this repro on a GoDaddy service. I may try some others later.
Also, if you happen to know - I'd be interested to know what features are likely to make my WCF services need full trust rather than medium trust. And any thoughts you have on whether it is a good idea to utilise such features (in context of least priv ideology).
For reference this is the web.config, including an additional endpoint suggested by Mike to try and resolve this.
<?xml version="1.0"?>
<configuration>
<system.web>
<customErrors mode="Off"/>
<compilation><!--debug="true"-->
<buildProviders>
<remove extension=".svc"/>
<add extension=".svc" type="System.ServiceModel.Activation.ServiceBuildProvider,System.ServiceModel, Version=3.0.0.0, Culture=neutral,PublicKeyToken=b77a5c561934e089"/>
</buildProviders>
</compilation>
</system.web>
<!-- When deploying the service library project, the content of the config file must be added to the host's
app.config file. System.Configuration does not support config files for libraries. -->
<system.serviceModel>
<services>
<service behaviorConfiguration="blah"
name="WCFServ.EvalService">
<endpoint address="http://www.abcdomain.com/WCFServ/WCFServ.EvalService.svc"
binding="basicHttpBinding"
contract="WCFServ.IEvalService" />
<endpoint address="http://abcdomain.com/WCFServ/WCFServ.EvalService.svc"
binding="basicHttpBinding"
contract="WCFServ.IEvalService" />
<!--<endpoint address=""
binding="mexHttpBinding"
contract="IMetadataExchange" />-->
<!--<host>
<baseAddresses>
<add baseAddress="http://abcdomain.com/WCFServ/" />
</baseAddresses>
</host>-->
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="blah">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://www.abcdomain.com/WCFServ/"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
</system.serviceModel>
<!--http://localhost/WCFServ/WCFServ.EvalService.svc-->
<startup><supportedRuntime version="v2.0.50727"/></startup></configuration>
Because you're using absolute URLs as your endpoint addresses, WCF needs to see a specific host header in HTTP requests in order to bind to those addresses.
Web servers are no different; if they're configured for a specific host, the request headers must have the host name or they won't serve up content. However, multiple host names can be bound to web sites, however, so sometimes a site may be tied to both www.example.com and example.com. Also, some web browsers, if you go to example.com and get a 404 or if the DNS lookup fails, will automatically retry the request at www.example.com.
I think the easiest thing for you to do to resolve your issue is to modify your endpoint(s) so they are host neutral. For example:
<services>
<service behaviorConfiguration="blah" name="WCFServ.EvalService">
<endpoint address="/WCFServ/WCFServ.EvalService.svc"
binding="basicHttpBinding"
contract="WCFServ.IEvalService"/>
</service>
</services>
<!-- Just leave this out
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://www.abcdomain.com/WCFServ/"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
-->
Make sure that you have endpoints defined without the www in your web config.
This page has some good explanations about WCF addressing:
WCF Adressing In Depth.
Is your problem solved by adding the following attribute on your serviceclass?
[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]