Likely an IIS configuration error. We have no experience using IIS. We'd recommend either Apache or NGINX. We have example configurations for both.
You can likely use IIS, we just will not be able to support you in configuration errors.
RequestLease() returns TF_E_INET when using HTTPS.Solved
Hi,
I have set up TFS server behind IIS using SCGI.The web url is in format https://server.domain.com/tfs/When I access the web page in the browser I get message that TFS is running:
Floating license server (TFS) is runningYou've successfully configured the floating license server (TFS) and you can access it.
I then save the server as shown below:
tf.SaveServer("server.domain.com/tfs/", 443, TF_SYSTEM | TF_REQUEST_OVER_HTTPS);
Save completes with TF_OK.I then proceed and call RequestLease() however it always returns with TF_E_INET.I tried different parameters in SaveServer() with and without ending slash but I could not get it working.RequestLease() always returns TF_E_INET for me.
I started Fiddler to try and track the issue.It first sends CONNECT request with completes fine:
CONNECT server.domain.com:443 HTTP/1.1HTTP/1.1 200 Connection Established
However the POST request completes with 404.I saw is that the POST request to server has endind protocol number which I am not sure if that is the correct use:
POST https://server.domain.com/tfs/:443 HTTP/1.1HTTP/1.1 404 Not Found
I then replayed the request with Fiddler and removed the :443 part and the request completed with HTTP/1.1 200 OK. However the response was the same HTML that I get for "Floating license server (TFS) is running".
What am I doing something wrong here?
Thank you,Martin
Wyatt,
Note I am getting the sample HTML saying "Floating license server (TFS) is running" so the IIS should be configured all good.
It looks to me the POST request is not properly sent to the server:
POST https://server.domain.com/tfs/:443 HTTP/1.1
It looks like improperly crafted with the :443 suffix.
Enable notification level logging on the TFS, restart it, then try again. See if the communication reaches the TFS. If not, then it's an IIS configuration error.
Just tested with latest TFS (4.3.2) and everything works fine for Apache and Nginx configurations.
Wyatt,
Does your POST request look like the one below:
POST https://server.domain.com/tfs/:443 HTTP/1.1
Please note the trailing :443 after /tfs/ which should not be there IMHO.
This is coming from the TFS client so it should not be IIS configuration issue.The IIS server replies with:"Floating license server (TFS) is runningYou've successfully configured the floating license server (TFS) and you can access it."
Thank you
This isn't a matter of opinion. The request is correct. Fix your IIS configuration. Or use Apache or NGinx and use our configurations as-is.
Wyatt,
I just confimed that URI syntax like https://server.domain.com/tfs/:443 does not work in IIS.
I have created new page that returns sample html output.The sample web page does not have anything to do with TFS.
Here is how the HTTP request looks like open I open the webpage in the browser. It works fine there.GET https://server.domain.com/test/ HTTP/1.1
Here is the modified request I am sending to the server using Fiddler. It returns 404 Not Found.GET https://server.domain.com/test/:443
IIS just does not work with the format you are using and it is not TFS configuration issue.
I can send you the real url to the TFS server and the test page. They are publically accessible at the moment.
The request from the TF library is correct. Fix your IIS configuration or use Apache or NGINX.
Wyatt,
I created a sample plain html page with no TFS.Here is the url: https://rtdlog.westeurope.cloudapp.azure.com/test/
The HTTP request in form below does not work in IIS.GET https://rtdlog.westeurope.cloudapp.azure.com/test/:443 HTTP/1.1
Don't put the TFS under a subdirectory. Use domains / subdomains only.
Wyatt,
This is not a TFS Server issue.IIS cannot handle the way you craft the POST request with /:443 suffix in URI.
Don't host at "https://server.domain.com/tfs/"
Do host at "https://server.domain.com"
Fix your IIS configuration.
Wyatt,
There is no TFS Server involved in this scenario.TFS Client is not sending requests that IIS can parse.
See this example:
curl --request GET https://rtdlog.westeurope.cloudapp.azure.com/<h1>TEST</h1>
curl --request GET https://rtdlog.westeurope.cloudapp.azure.com/:443...<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/><title>404 - File or directory not found.</title>...
OK. So don't use IIS. Or fix the configuration. Either one.
Or, like I've said half a dozen times in this thread: use Apache. Or use NGINX.
We don't provide support for IIS. You can contact Microsoft and pay for IIS support and they'll be glad to help you configure IIS.
Or use Apache and use our configuration.
Or use NGINX and use our configuration.
Wyatt,
Honestly I do not understand why you are so reluctant to help here.It is a simple implementation change for the way TFS client crafts the URI.
Great product, but hey man... the way you handle support issues got me seriously thinking of moving away.What I am hearing is "it is working on my machine" for all day long just to find out that IIS is not supported.
And no - there is no IIS configuration to be fix, either by me or Microsoft. This is implementation detail in IIS. It is the way it works.And no - hosted TFS is not an option for us.
You can workaround it with simple fix - just putting the port where it works for all web servers i.e. between the hostname and the path.
curl --request GET https://rtdlog.westeurope.cloudapp.azure.com:443/
It is a simple fix. But you do not want to support us for some reason.
We might change the way the TF library constructs URLs. This is very low priority.
Also, there are several immediate solutions available (don't use IIS, fix IIS configuration, use Apache, or use NGINX).
Also, as I've already said above, use host address without trailing directories:
Not "example.com/tfs/", not "example.com/tfs", not "example.com/"
This: "example.com"
Again,
IIS is not misconfigured. Therefore - nothing to be fix there.Apache and Nginx are not an option for this customer.Hosted TFS is not an option for this customer.
I will try to use the proposed workaround with no path or trailing slashes.
Proposed quick solution for TurboFloat client would be to skip concatenation of port number after path for default ports 80 and 443. This will resolve 99% of the issue.
Not an opinion - this is what specs say how URI should be constructed.https://www.w3.org/Addressing/URL/5_BNF.html#z12It is pure luck that Apache and Nginx allow for incorrect URI implementation.
Kind regards
Apparently there is already implementation to remove the default ports.When I used host name only without path the request made it through.No port number was appended in this case.
Here is how the POST request looks like:POST https://rtdlog.westeurope.cloudapp.azure.com/ HTTP/1.1
I am calling SaveServer("rtdlog.westeurope.cloudapp.azure.com", 443, TF_SYSTEM | TF_REQUEST_OVER_HTTPS)
The response from TFS this time is the initial HTML page.Here are the logs from TFS when I call RequestLease().
2020-05-27, 20:43:02 <notification>: New connection from IP on SCGI: ::ffff:127.0.0.12020-05-27, 20:43:02 <notification>: The TurboFloat Server was accessed via a browser, HTML instruction page rendered.
What could be the reason that TFS thinks that I am calling through browser and not from the API?
Middleboxes, routers, or the server itself stripping off unknown headers that the TurboFloat library sets when it sends the request.
TurboFloat client sends POST request where browser sends GET request.Why do we need HTML instruction page for POST requests?
To filter out bad/dumb clients early on.
Point of filtering is the same for HTTP verb type and Agent type.Allow all POST requests and show HTML for all GET requests regardless of Agent type for both.
It brings nothing for usability of the product if you would filter by Agent type.Only integration headaches.Malicious clients will craft the agent type right.. bad/dump clients hurt only the integration story.
We wont be doing that. Changing user agents is a non-starter. Right now we fake being Internet Explorer 11 on Windows 10 (regardless of the actual OS) because proxies and firewalls are often misconfigured.
We used to have unique specific user agents. It caused more problems than it solved. Trust me, weve been doing this for a while. Any peculiar behavior is because were working around some network nonsense.
So, configure your IIS to pass along all headers to the TFS instance, and dont strip headers in any firewalls/routers/etc.
I will validate if agent type is changed on server side and will let you know.
Still not getting why dropping requests for non expected agent types increases security of the product.
Its not user agent that TFS cares about. Its other headers.
It doesnt increase security. It decreases noise.