@Greg O’Lone yep, I would never encourage a silent breaking change, as I wouldn’t appreciate that myself if the situation were reversed. It would be better to find a way to introduce the feature I want, without breaking other users.
So, for example, there could be an option such as “Use relative URLs for Standalone” which would be “off by default” and therefore not break any existing user. But a user like myself could simply turn that new flag on. Then, in the methods inside Xojo where the URLs are constructed, it would just be a simple branch, checking that flag and either constructing the URL with or without the leading slash.
To my mind, this seems relatively simple and harmless, and would allow for Xojo web apps to be easily placed behind a proxy without imposing additional processing or URL conventions.
If I’m building an app for my own product/service, or doing work for a client, I dislike the idea of needing to tell them how their URLs need to be structure simply because I choose a tool that either imposes unnecessary URL implications, or requires some of the CPU to be used up in post-processing.
There are several reasons why mod_proxy_html is not an ideal solution:
- Unnecessary CPU and memory overhead
- Time delays
- “weak link” that could go wrong
The more configuration points there are, the more fragile the deployment is, so eliminating any weak links in the process is a great idea. The less work-arounds that are added, the less error-prone the solution.
@Phillip Zedalis, I may have to go through the subdomain route if I want to avoid the processing overhead of mod_proxy_html. There are several reasons why the subdomain approach is not ideal:
- Imposes URL requirements for deployment that may be undesirable
- Requires additional security certificate for new domain
- Requires new subdomain for each app deployment
@John Joyce, yes, I suppose I am making an effort to be able to ensure that I can deliver the solutions that I am desiring. Whether I’m doing work for myself or for a client, I like to be able to do what they ask and what I think the customer will want. When the technology we use imposes upon our ability to deliver the desired solution, I take the time to try to deliver the best I can. In this case, I think there are some deployment restrictions which impose upon “business requirements.” For example, I do not want to tell a client that I can’t do what they want just because of a technology selection that I have recommended. Especially when the solution to fix it is as simple as removing a leading slash character from system-generated URLs so that the typical proxy configuration can cleanly pass-through the requests to the standalone server.
If there is a desire to have three apps on a server, which I would like to deliver like this:
Because of this leading slash, I would need to now “force” a deployment that either imposes additional processing on all requests (i.e. mod_proxy_html) or requires URLs to look more like this:
Whenever possible, I do not like to have to make “business requirement” decisions because of technology selection, or have “business requirements” unnecessarily changed because of technology selection. There is one exception to this, and that is when the “business requirement” was unreasonable and existing technology available does not operate this way. However, in this case, this is an “unreasonable” imposition by the technology because the alternatives do not impose this.
For example, if a client said to me, “can we reverse the URL so that the domain is the last element?” I would have to reply, “No, I’m sorry that is not how URLs work.” In that case, all browsers require that the domain/host is the first element after the scheme (if no user is specified, etc.); that is not something I can change; so the request to put the domain at the end of the URL is not reasonable from a business requirement. But a business requirement that says that the URL should use the standard organization URL appended with the app name (as in the first set of examples) is a perfectly reasonable business requirement which now has to change because of a single slash character; or I have to let them know that there will need to be additional processing (which costs money and time, and adds a fragile link to the app deployment) because of a technology selection that I recommended. I have been in plenty of meetings where these kinds of discussions take place, and then someone says, “well maybe we shouldn’t choose technology XX in the first place.” I do not like Xojo to receive that kind of response from potential clients or projects.