Currently it is not possible to access Liferay directly and through the proxy at the same time when a custom context / proxy path is involved.
There are two possible ways to do this, but they are not working:
Set the Proxy path
This is the web server's configuration that we used to test the /portal proxy path:
Using the above configuration, if we go to myip:8090/portal, it will be proxied to localhost:8080. This is where the property "portal.proxy.path" comes in; Without setting that property to be "/portal", wrong URLs will be generated, because in essence, the portal is reached at localhost:8080 and doesn't know about the added "/portal". With this setting, when generating the URL, Liferay will append the proxy path to its base relative location, and serve the resources on the new path, which will now be "/portal".
However, if we are accessing the portal from "localhost:8080", this time none of the resources will be loaded, as it will attempt to load them at localhost:8080/portal/..., which doesn't exist, resulting in a lot of 404 error messages. On the other hand, adding the "/portal" to the URL works when accessing through Apache, as myip:8090/portal is rerouted to localhost:8080.
Now if we access the portal from "localhost:8080/portal" (basically, a page that doesn't exist), it will try to redirect to the "Not Found" page, through localhost:8080/portal/c, however, that also doesn't exist, so another redirect is coming, resulting in the infinite redirect loop.
This configuration works when accessing the portal through the Apache, as it is exactly what needs to be configured in order for a path'd webproxy to work.
Setting the Context path
Setting the Context path and adhering to it will work when accessing the portal directly, but breaks the proxy-approach. Small change to the above configuration (added the "/portal" at the end of liferay-ip), plus making the necessary changes on Tomcat so that the context path will be "/portal":
With this configuration, accessing the portal directly at localhost:8080/portal works, as long as the portal.proxy.path is not set, because all the URLs are correct, the resources are reachable both for the portal, and for the portlets as well. If portal.proxy.path is set, then it will append the proxy path with the context path, resulting in URLs that look like "localhost:8080/portal/portal".
However, accessing the portal from myip:8090/portal (which redirects you to localhost:8080/portal) causes an issue with the URLs of plugins. When generating them, they will be generated with the "/portal" context instead of the "/" context, which will mean that the resources won't be found. (localhost:8080/portal/notifications-portlet/... instead of localhost:8080/notifications-portlet/..., where it actually is).
It would be great to modify the portal so that you can access it both with localhost:8080/portal (directly) and with myip:8090/portal (through Apache)