[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
[11:15:05 CDT(-0500)] <athena> ah 
[11:15:30 CDT(-0500)] <EricDalquist> so now resource responses can actually set the status code
[11:15:39 CDT(-0500)] <EricDalquist> and arbitrary headers
[11:16:32 CDT(-0500)] <athena> yay!
[14:08:24 CDT(-0500)] <EricDalquist> ok ... just merged in all that caching refactoring
[14:08:31 CDT(-0500)] <EricDalquist> let me know if you see any weirdness athena
[14:08:37 CDT(-0500)] <EricDalquist> but I think it is pretty well tested
[15:49:34 CDT(-0500)] <b-sure> hello uMobile devs. Do you know if there is a specific configuration you need to make to enable the mobile view of the NewsReaderPortlet? I'm using an overlay of the 3.0.2 version.
[15:50:03 CDT(-0500)] <b-sure> this would be viewing the portlet through uMobile
[15:50:30 CDT(-0500)] <b-sure> for some reason, its displaying in the normal view
[15:52:37 CDT(-0500)] <athena> hm
[15:52:42 CDT(-0500)] <athena> are you getting the mobile view for other stuff?
[15:53:09 CDT(-0500)] <b-sure> only for the directory porltet
[15:53:26 CDT(-0500)] <b-sure> othewise everything looks like a shrunken portlet
[15:54:08 CDT(-0500)] <athena> do you by chance have custom theme names?
[15:54:09 CDT(-0500)] <b-sure> I'm not sure if maybe something in the db data may be causing this. or maybe a config chagne
[15:54:19 CDT(-0500)] <b-sure> I think it is DLMXHTML
[15:54:26 CDT(-0500)] <b-sure> without the space?
[15:54:41 CDT(-0500)] <athena> do you have the mobile theme configured? and is that theme showing up when you go to the portal from a mobile browser?
[15:54:43 CDT(-0500)] <b-sure> oh we do have our custom uofchicago theme
[15:54:56 CDT(-0500)] <athena> the portlets are looking at the theme name
[15:55:01 CDT(-0500)] <b-sure> I don't think I have the mobile theme configured