This article is primarily for vendors of redistributable web applications shipped along with UWS. It describes best practices for registering applications with UWS on machines with unknown configurations.


Problem Definition
Ideally, every ISV shipping a web application, wants it to be hosted at http://host:80/. Since everyone wants it, it's likely that when your application gets installed, http://*:80/ is already taken. ISVs may be tempted to deal with this problem by either asking users about which port to use, or finding a free port themselves. Both of these approaches are not reliable (users are prone to not knowing which port is free, and ISVs often have free port search routines of varying degree of reliability). But most importantly, asking users or looking for a free port yourself is unnecessary as UWS can do it for you.


Registration Basics
When you register an application with UWS, whether you are using a command line utility, our application registration API, or do it manually using UWS Explorer application management console, same best practice principles apply:

• Register your application on multiple ports.
  
• Use non-blank (non-"/") virtual directory that is likely to be unique.
  
• Use http://*:0/ endpoint regardless whether you use one or multiple listen endpoints.
  

Registering on multiple ports
The best reason to do it is there's pretty much no downside for doing it, while upside is that your application gets more likely to be registered. When you tell UWS to register an application on an endpoint with a hard-coded port number, UWS will check whether the endpoint is available, and if it's taken, it will remove the endpoint from the list. Therefore, if you specify only one endpoint with a hard-coded port and "/" virtual directory, you can rest assured that certain number of your registration attempts will fail. If your hard-coded port of the sole endpoint is 80, then you will have very high registration failure rate.


Using virtual directories other than "/"
The most compelling reason to use a virtual directory is that modern web servers, like IIS 6, 7, and UWS, can co-exist and share popular ports like 80, as long as applications listening on those ports use different virtual directories. On machines running Vista, Win 7 & 8, Windows 2008 and 2008 R2, your application is very likely to be hosted on port 80, as long as your virtual directory name does not duplicate other applications' virtual directories.

Another, more obscure, but still important reason, is that with "/" vdir, cookies your application generates, will be sent to other applications with "/" vdir on the same host. In other words, if there are two or more applications hosted on the same host on different ports with no virtual directory, all of them will get cookies of each other, which is a serious security and quality risk. For example, if you register an application as http://*:12345/ and set "userid" cookie in it, and there is another application hosted by IIS or UWS on http://*:23456/, this second application will get your "userid" cookie from the same client, because cookies are not port-sensitive. They are only host and vdir (path) sensitive.

The only case when you can't use virtual directory is when your application needs access to scripts "/aspnet_client" folder. Applications using Crystal Reports fall in this category.


Use port 0 (http://*:0/ endpoint) to let UWS find free port for you
No matter whether you are hosting an application on one port or more, even if it's just one port, make it port 0. Telling UWS to use port 0 means that UWS will find a free port and assign it to your application. Since there is virtually no downside for using multiple ports, go ahead specify http://*:80/ if you want, but also add http://*:0/ as well. It will ensure that at least one endpoint will be there for your application even if all other desirable ports like 80, 8080 and 443 are taken in exclusive mode by some outdated server.

The nice thing is that assigned free port will not change when your application gets reinstalled or goes through upgrade: UWS remembers which port it initally assigned to your application, and will use it again when your application is re-installed or upgraded - as long as you keep application ID the same between versions of your app.

Scroll down to read about finding your application's URL after registering it.

For installers using UWS build 14 or older, and for other cases when application URL needs to be made manually

Using http://*:0/ endpoint means that on every box where your application is registered, it will be hosted on a different port. How do you craft a link that you can give to users to access the application if you don't know the ports UWS assigned to the application? UWS redirector application is the answer.

UWS Redirector is UWS' own little web application installed along with the web server and hosted on well-known ports at http://*:7756/ (as well as http://*:5677/ and http://*:56777/). Its main task is to redirect to your application by application ID, regardless what port your application is hosted on.

Here's the format of the redirection URL:


In the string above,

• <host> is machine's IP or hostname;
  
• <appGUID> is your application ID. It's a required parameter;
  
• <port1> and <port2> are optional port numbers defining priority of redirection if your application is registered on multiple ports. For example, if you registered your application on ports 80, 8888 and 0, you would specify ",80,8888" after application GUID. This will ensure that redirector application will try to redirect to an endpoint with port 80, if application is actually listening there, instead of redirecting to whatever is the random free port was assigned by UWS. However, if the endpoint with port 80 was taken and UWS was unable to put your app on port 80, the redirector will try to see if your application is on port 8888, and only if it's not there, it will use next endpoint.
  If this parameter omitted, ports 80 and 443 will be picked first if the application uses them, and then the first actual endpoint used by the application will be picked.
  
• <defaultResourcePath> is optional resource path inside application structure. If omitted, UWS will redirect to the default document.
  
• <queryString>
  

Message was deleted by a Moderator.

Message was deleted by a Moderator.

Message was deleted by a Moderator.

Message was deleted by a Moderator.

Message was deleted by a Moderator.