Some clarifications on XData (and Sphinx)

[van_den_Berg_Mark]

I moved my XData & Sphinx test server applications to my VPS in the cloud. First I tried to run from the VPS IP address on port 2001. All working great, so I ultimately changed everything to my server's address (say: https://subdomain.domain.com). Important to note that I have a (commercial) web application running on this VPS via IIS (i.e. https://subdomain.domain.com/the-app/portal). For this reason, I also added the following statement (I prefer port 443 as to have a minimum of firewall issues) to my servers:

SparkleHttpSysDispatcher.HttpSys.KeepHostInUrlPrefixes := true;

All is working well, but I noticed some things that I like to clarify to ensure all is running correctly (and secure):

1. The certificate (Let's Encrypt) was already bound to https://subdomain.domain.com for the commercial web application, so additional paths (e.g. https://subdomain.domain.com/example/xdata) share the same certificate. Correct?
2. Initially I forgot to add the SparkleHttpSysDispatcher.HttpSys.KeepHostInUrlPrefixes := true; to the Sphinx server but it appeared to make no difference? Is this not required for a Sphinx server?
3. On the first run I also forgot to reserve the URL's (https://subdomain.domain.com/example/xdata and https://subdomain.domain.com/example/sphinx) with the TMSHttpConfig tool. Nevertheless, it worked without issue. How can this be? Any other URL (e.g. http://+:2001) immediately raised an exception if not registered at server start....

Thanks!

[wlandgraf (Wagner Landgraf)]

@van_den_Berg_Mark

The certificate (Let's Encrypt) was already bound to https://subdomain.domain.com for the commercial web application, so additional paths (e.g. https://subdomain.domain.com/example/xdata) share the same certificate. Correct?

Correct. The certificate is not bound to a specific path, but at IP/domain level.

@van_den_Berg_Mark

Initially I forgot to add the SparkleHttpSysDispatcher.HttpSys.KeepHostInUrlPrefixes := true; to the Sphinx server but it appeared to make no difference? Is this not required for a Sphinx server?

The BaseUrl property is used to set the http.sys URL to be listened. When KeepHostInUrlPrefixes is false (default, for backward compatibility), the host in the BaseURL is replaced by a +. Thus, regardless if your BaseUrl is either http://test:2001/tms/xdata or http://foo:2001/tms/xdata, XData will use the value http://+:2001/tms/xdata.

Setting KeepHostInUrlPrefixes to True will disable this behavior and keep the original value, allowing the serve to only respond to requests to specific domain, not any.

@van_den_Berg_Mark

On the first run I also forgot to reserve the URL's (https://subdomain.domain.com/example/xdata and https://subdomain.domain.com/example/sphinx) with the TMSHttpConfig tool. Nevertheless, it worked without issue. How can this be? Any other URL (e.g. http://+:2001) immediately raised an exception if not registered at server start....

Probably you had a catch all reservation already registered, like http://+:80/ and http://+:80/example.