[11:04:30 CDT(-0500)] <athena> EricDalquist: have you run into server environments where java calls to request.getScheme() report HTTP, even though from the user perspective it's HTTPS?
[11:04:36 CDT(-0500)] <athena> usually a loadbalancer / firewall thing
[11:04:44 CDT(-0500)] <EricDalquist> no
[11:04:49 CDT(-0500)] <EricDalquist> but we always use AJP
[11:05:02 CDT(-0500)] <EricDalquist> primarily because of all of the issues with a https->http proxy
[11:05:16 CDT(-0500)] <athena> i get the impression this is more common when it's because of some kind of complex hardware-based loadbalancer
[11:05:27 CDT(-0500)] <athena> running into it right now, but we had some setups like that at yale
[11:05:32 CDT(-0500)] <EricDalquist> hrm
[11:05:40 CDT(-0500)] <athena> mostly wanted your perspective about how broken that is as a setup and whether we want to try to support it
[11:05:41 CDT(-0500)] <EricDalquist> so the portal is generating incorrect urls?
[11:06:09 CDT(-0500)] <athena> well the map portlet isn't working, because it tries to read a file it hosts via httpclient
[11:06:17 CDT(-0500)] <athena> and it's auto-generating the URL
[11:06:23 CDT(-0500)] <EricDalquist> oh ...
[11:06:25 CDT(-0500)] <EricDalquist> well that is bad
[11:06:33 CDT(-0500)] <EricDalquist> we have issues with that here
[11:06:36 CDT(-0500)] <EricDalquist> if one of our servers
[11:06:37 CDT(-0500)] <athena> similarly the google APIs are being included via http instead of https
[11:06:49 CDT(-0500)] <EricDalquist> tries to access my.wisc.edu
[11:06:56 CDT(-0500)] <EricDalquist> that server will drop off the network for ~2 minutes
[11:07:10 CDT(-0500)] <athena> ick
[11:07:12 CDT(-0500)] <EricDalquist> yeah
[11:07:24 CDT(-0500)] <EricDalquist> due to the network magic the layer4 load balancer does
[11:07:26 CDT(-0500)] <athena> so i mean i can just write some code that'll allow configuration of whether it should use http or https
[11:07:32 CDT(-0500)] <EricDalquist> so in general from what I've see
[11:07:34 CDT(-0500)] <EricDalquist> seen
[11:07:35 CDT(-0500)] <athena> but also calls to request.isSecure are going to be wrong
[11:07:53 CDT(-0500)] <EricDalquist> it is "very bad practice" for an app to make any sort of network connection back to itself
[11:08:03 CDT(-0500)] <EricDalquist> unless explicitly configured to
[11:08:11 CDT(-0500)] <EricDalquist> but that isSecure thing
[11:08:19 CDT(-0500)] <EricDalquist> that seems like it could be a config option ifneeded
[11:08:24 CDT(-0500)] <EricDalquist> add a flag in portal.properties
[11:08:48 CDT(-0500)] <EricDalquist> and modify the portal http servlet request wrapper to look for the flag and override the actual value if set
[11:08:56 CDT(-0500)] <athena> i guess maybe with our new filter files we can get away from the portlet connecting back to itself without adding a configuration headache
[11:09:08 CDT(-0500)] <EricDalquist> what is it trying to do?
[11:09:09 CDT(-0500)] <athena> so maybe we should just start using those values in portal.properties and some of hte problem will go away
[11:09:17 CDT(-0500)] <athena> just reading in the default data
[11:09:26 CDT(-0500)] <athena> which could be remote but doesn't have to be
[11:09:44 CDT(-0500)] <EricDalquist> ah so the portlet allows for a remote data source?
[11:09:57 CDT(-0500)] <EricDalquist> yeah I'd make it so the default config is read locally
[11:10:09 CDT(-0500)] <athena> and we can set up the default use case to use the portlet overlay
[11:13:20 CDT(-0500)] <EricDalquist> on a positive note ... while fixing the caching stuff
[11:13:36 CDT(-0500)] <EricDalquist> I also realized that we were not letting resource responses set browser headers
[11:13:39 CDT(-0500)] <EricDalquist> so that works now