I want IIS Express to server a folder. In the output I get:
Successfully registered URL "http://localhost:8080/" for site "Development Web Site" application "/"
I would like to change the URL. The closest I have found is the following in applicationhost.config:
<site name="Development Web Site" id="1" serverAutoStart="true">
<application path="/">
<virtualDirectory path="/" physicalPath="%IIS_BIN%\AppServer\empty_wwwroot" />
</application>
<bindings>
<binding protocol="http" bindingInformation=":8080:localhost" />
</bindings>
</site>
If I change localhost to something like "localhost.test.com" I still see a message that the URL being registered is "localhost". Am I missing something?
This is an example from Microsoft for the binding.
<binding protocol="http" bindingInformation="127.0.0.1:8080:localhost.test.com" />
https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/sites/sitedefaults/bindings/binding
If you are planning to leave it running, enable the full featured IIS. This is a Windows 10 example.
https://msdn.microsoft.com/en-us/library/ms181052(v=vs.80).aspx
Lastly, if you want to change urls, you can use the URL rewrite feature:
https://blogs.msdn.microsoft.com/friis/2016/08/25/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world-apps/
If you are trying to go to localhost.test.com, your DNS is likely going to point you to test.com and not stay within your server, unless you update your host file, which would be weird, so I don’t recommend doing that.
Related
In my code I am consuming an asmx web service and recently I changed the url from http to https, for eg.
Ealier the url was:http://xyz#xyz.com/abc/webservices/pqr.asmx, and now it has been changed to: https://xyz#xyz.com/abc/webservices/pqr.asmx.
In my web.config I have made the following changes:
<system.serviceModel>
<basicHttpBinding>
<binding name="ApplicationMessagingWSSoap12" closeTimeout="00:02:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:02:00"
maxBufferSize="2147483647" maxBufferPoolSize="524288" maxReceivedMessageSize="2147483647"
transferMode="Buffered">
<readerQuotas maxDepth="2000001" maxStringContentLength="2000001"
maxArrayLength="2000001" maxBytesPerRead="2000001" maxNameTableCharCount="2000001" /
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://xyz#xyz.com/abc/webservices/pqr.asmx" binding="basicHttpBinding" bindingConfiguration="ApplicationMessagingWSSoap12" contract="MSSInterface.ApplicationMessagingWSSoap" name="ApplicationMessagingWSSoap12" />
</client>
</system.serviceModel>
But I am getting the issue:
The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.
I tried all the techniques I found over net but no luck yet.
Please can anybody help me with a solution , Thanks in advance :)
I was getting the issue after I changed the url of the web service my code was consuming from http to https. I increased the size of message in the binding tag but still i was facing the issue, but after adding the following line it solved my issue:
<httpsTransport maxReceivedMessageSize="2147483647" />
Posting it, so that my answer may help someone in future with similar kind of issue.
thanks:)
I have an ASP.NET webforms application that uses windows authentication when developing locally. The first time that I debug the webapp, IIS Express starts up and the pages work as expected. If I stop debugging and then start it again, I get in this endless cycle that no matter what page I go to, it always forwards to the login.aspx page and then to my Default.aspx page.
I can keep clicking on different pages, but it still keeps going to the Login then Default. I should be authenticated at this point and not be forwared to login.aspx. I believe it is because IIS express thinks that I am not authenticated. However, when I look at my cookies, I see that there is a ASP.NET_SessionId cookie so I don't think this should be happening.
If this helps, I have this in my page_load for login.aspx
if (authSection.Mode == AuthenticationMode.Windows)
{
//stuff happens here
Response.Redirect("Default.aspx");
return;
}
To fix the problem, I have to kill IIS express and start debugging again. I'm not really sure why it thinks that I am not authenticated. Even though this isn't the same question, I tried the answer provided here: https://stackoverflow.com/a/19515891/888617 and it did not help.
Edit: This actually doesn't appear to solve my issue.
It turns out the issue was specific to Chrome. I was getting this issue when debugging and had to kill the IIS express process for it to resolve itself. However, I found a more perminate solution by doing the following.
In %userprofile%\documents\IISExpress\config\applicationhost.config insure that the overrideModeDefault is set to allowed for windowsAuthentication and anonymousAuthentication like this:
<section name="anonymousAuthentication" overrideModeDefault="Allow" />
<section name="windowsAuthentication" overrideModeDefault="Allow" />
Your authentication section should also look like this. Note the only provider is NTLM.
<authentication>
<anonymousAuthentication enabled="false" userName="" />
<basicAuthentication enabled="false" />
<clientCertificateMappingAuthentication enabled="false" />
<digestAuthentication enabled="false" />
<iisClientCertificateMappingAuthentication enabled="false">
</iisClientCertificateMappingAuthentication>
<windowsAuthentication enabled="true">
<providers>
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
This section should also be in the web.config.
<authentication>
<windowsAuthentication enabled="true">
<providers>
<clear />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
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
This may be an extremely simple quesiton, but can I use node.js in a windows server 2008 environment with IIS? Is there a "Microsoft" library or some other solution that works better?
Sure you can, check out the IISNode Project.
You can install Node.js on Windows, but it is its own server, so unless you're using IIS as a proxy to it, there's no need for IIS at all. Note, though, the following as quoted from Node.js's installation instructions:
Neither [Windows] builds are satisfactorily stable but it is possible to get something running.
You essentially have two routes for running a Node.js application via IIS.
IISNode
Reverse Proxy using Application Request Routing
If you are dedicating an entire application to Node.js and simply need the public facing endpoint to work through your existing IIS Application, I would suggest using ARR to route the entire site through. I'm doing this for a couple of projects, and it works fairly well.
To be honest, I haven't liked IISNode, as it seems like you are making alien endpoints in your node code vs. IIS. It works, and if you are targeting Azure in particular it may be your best option. It also may be the best option if you have to shoe horn it into an existing .Net application.
I have been using Node on Windows with Cygwin and had few problems. You can use IIS to serve on default port 80 and run your Node apps on different ports.
If you want to proxy then most are using Nginx.
You can build node.js on Windows, but it's not recommended to use it due to possible stability issues. If IIS is using thread based pools then you shouldn't even use it as a reverse proxy (on linux based systems nginx is usually used to do this) for node.js because pool may quickly become fully loaded. If you want something similar to node.js on windows then you should try to look at manos.
I wanted to make it as easy as possible.
Issues with iisnode
I installed iisnode and ran the samples with no problem but...
I tried to deploy it on IIS with iisnode, but I had to bundle my meteor app and then deploy it as a node app. The problem I ran into discouraged me. I could not get fibers to install at all. compilation process kept trowing errors, so I gave up.
Reverse Proxy IIS
What I did to solve this for me is use a reverse proxy on IIS.
see my post on meteor forum
My final web.config entry was:
I did the same, however, the way I had the reverse proxy on IIS to use
a sub folder on the domain threw me of.
I was not aware that by using ROOT_URL we could specify the a sub
path.
example, if i run the following command inside my meteor app folder:
set ROOT_URL=http://localhost:3100/n/todos && meteor
I will be able to access my app at http://localhost:3100/n/todos,
notice I omitted the trailing /. And if we try to surf to the
address http://localhost:3100/n or http://localhost:3100/ will
give us an error Unknown path.
So, when I first setup the reverse proxy, I was getting the Unknown
Path error every time.
Turns out that on my IIS config, I have to specify the
http://localhost:3100/n/todos as the url value on the action, please
notice the "n/todos" at the end.
So my rewrite rule ended up like this: [file #
c:/inetpub/wwroot/web.config]
```
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="TODOs meteor app. Route the requests" stopProcessing="true" enabled="true">
<match url="^n/todos/(.*)" />
<conditions>
<add input="{CACHE_URL}" pattern="^(https?)://" />
</conditions>
<action type="Rewrite" url="{C:1}://localhost:3100/n/todos/{R:1}" /> <!-- I was missing the /n/todos here -->
<serverVariables>
<set name="HTTP_ACCEPT_ENCODING" value="" />
</serverVariables>
</rule>
</rules>
<outboundRules>
<rule name="TODOs ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1" enabled="false">
<match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://localhost:3100/(.*)" />
<action type="Rewrite" value="/n/todos/{R:2}" />
</rule>
<rule name="TODOs RewriteRelativePaths" preCondition="ResponseIsHtml1" enabled="false">
<match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^/(.*)" negate="false" />
<action type="Rewrite" value="/n/todos/{R:1}" />
</rule>
<rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
<match filterByTags="A, Form, Img" pattern="^http(s)?://localhost:3100/(.*)" />
<action type="Rewrite" value="http{R:1}://localhost/{R:2}" />
</rule>
<preConditions>
<preCondition name="ResponseIsHtml1">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>
```
Thanks
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)]