+- Atozed Forums (https://www.atozed.com/forums)
+-- Forum: Atozed Software Products (https://www.atozed.com/forums/forum-1.html)
+--- Forum: IntraWeb (https://www.atozed.com/forums/forum-3.html)
+---- Forum: English (https://www.atozed.com/forums/forum-16.html)
+----- Forum: IntraWeb General Discussion (https://www.atozed.com/forums/forum-4.html)
+----- Thread: IWBootstrap app and Apache (/thread-1331.html)
IWBootstrap app and Apache - troberts - 10-20-2019
I have an IWBootstrap app based on one of the bootstrap demos. I have compiled it as a service and configured it to run on port 44001 and it runs correctly when accessed directly via the LAN using the server's local IP address. It switches from desktop to mobile as required.
I am wanting to deploy it with Apache. In the conf file I have created a VirtualHost entry for it as follows:
<VirtualHost *:80>
ServerName mywebsite.com
ProxyPass / http://127.0.0.1:44001/ disablereuse=on
ProxyPassReverse / http://127.0.0.1:44001/
</VirtualHost>
I can browse to the website from outside, but the desktop version is always rendered. It does not switch to the mobile version when browsing to it from a mobile device. Any ideas?
RE: IWBootstrap app and Apache - Alexandre Machado - 10-22-2019
How does it switch from desktop to mobile? Is it based on the port?
RE: IWBootstrap app and Apache - troberts - 10-23-2019
(10-22-2019, 08:07 AM)Alexandre Machado Wrote: How does it switch from desktop to mobile? Is it based on the port?I guess it's based on the browser type. All I did was take one of the sample IWBootstrap applications. When I browse to locally it from my PC it renders in desktop mode and when I browse to it (locally) on my phone it renders in mobile mode. But when accessing it from outside via Apache it only renders in desktop mode no matter what the client is. The reverse proxy functionality in Apache must not be passing on whatever is needed to make it switch to mobile mode.
RE: IWBootstrap app and Apache - troberts - 10-24-2019
(10-23-2019, 09:36 AM)troberts Wrote:I can confirm that it's not on the browser type. I tried displaying the browser name and it correctly reports "Chrome Mobile" whether I browse to the site directly via the LAN IP address, or from outside via the Apache server. My next line of thinking is that the bootstrap application must decide how to render the output based on the screen resolution. If this is the case then perhaps the reported resolution is being changed as it passes through the Apache server. I'm going to do some tests to determine whether it is or not.(10-22-2019, 08:07 AM)Alexandre Machado Wrote: How does it switch from desktop to mobile? Is it based on the port?I guess it's based on the browser type. All I did was take one of the sample IWBootstrap applications. When I browse to locally it from my PC it renders in desktop mode and when I browse to it (locally) on my phone it renders in mobile mode. But when accessing it from outside via Apache it only renders in desktop mode no matter what the client is. The reverse proxy functionality in Apache must not be passing on whatever is needed to make it switch to mobile mode.
RE: IWBootstrap app and Apache - kudzu - 10-25-2019
As far as I recall it does use screen resolution to adjust between mobile and desktop. You can see this by reducing a browser windows size on desktop and BS templates will change to mobile layout.
AMP (Accelerated Mobile Pages) can have a play in this as well. AMP is a module installed on some installations. Explicit AMP often forces pages into mobile presentation only.
RE: IWBootstrap app and Apache - troberts - 10-25-2019
(10-25-2019, 03:52 PM)kudzu Wrote: As far as I recall it does use screen resolution to adjust between mobile and desktop. You can see this by reducing a browser windows size on desktop and BS templates will change to mobile layout.Thanks for your suggestion. I have found the problem. I compared the source of the rendered pages and it was evident that when browsing from outside via the domain name and Apache, Apache was wrapping the page in a frameset. After some investigation I discovered that Apache does this if the domain name is a simple URL redirect. Once I changed the settings on my hosting account from url redirect to using the A record in the name server configuration everything started working.
AMP (Accelerated Mobile Pages) can have a play in this as well. AMP is a module installed on some installations. Explicit AMP often forces pages into mobile presentation only.
I now have multiple Intraweb websites (each with their own domain name) running on the same webserver, all accessed via a single IP address and port 80. The websites run as Windows services and Apache operates as a reverse proxy, directing requests to the appropriate service. I am happy to write up some documentation about how to set this up if anyone else would find this useful.
RE: IWBootstrap app and Apache - Joao Lira - 10-27-2019
Hi,
I think that it would be a great contribution to know your solution to such a scenario. Could you, please, share more information on this?
Thanks in advance!
Joao Lira
RE: IWBootstrap app and Apache - kudzu - 10-28-2019
"After some investigation I discovered that Apache does this if the domain name is a simple URL redirect. Once I changed the settings on my hosting account from url redirect to using the A record in the name server configuration everything started working."
This doesnt seem to me like standard Apache behavior but instead some method your hosting provider is using.
RE: IWBootstrap app and Apache - troberts - 10-29-2019
(10-28-2019, 04:27 PM)kudzu Wrote: "After some investigation I discovered that Apache does this if the domain name is a simple URL redirect. Once I changed the settings on my hosting account from url redirect to using the A record in the name server configuration everything started working."Possibly that is the case. But I found other cases on forums unrelated to Intraweb where people had experienced exactly the same issue. Thanks everyone for your help with this one. I have described my setup in another post in case it's useful to others.
This doesnt seem to me like standard Apache behavior but instead some method your hosting provider is using.