[Building Sakai] Chrome 30 and HTTP

[Matt Clare]

Hi Bill,

	Parts of the solution Sam mentioned about X-Forwarded-Proto on Friday, but Sam's recent E-mail http://collab.sakaiproject.org/pipermail/sakai-dev/2013-October/024772.html  and link summarizes the solution well.  The X-Forwarded-Proto header is the path Brock University will ultimately take when we migrate from 2.8 to 2.9 in the spring, but at the moment our load balancer has more than the capacity to affect and support  this change and 5 hours into it hitting production we have neither perceived or measured an impact on responsiveness.

	.\.\att

 ::  Matt Clare
Manager, eLearning
 Centre for Pedagogical Innovation 
Part-time Instructor
 Interactive Arts and Sciences
Brock University, Niagara Region, Ontario, Canada
http://brocku.ca/pedagogical-innovation    905 688 5550 xt 4539   Office: SBH321

Running for Parkinson's Research this October http://www2.michaeljfox.org/site/TR/Sponsored/TeamFox?px=1624726&pg=personal&fr_id=1400

On 2013-10-09, at 12:28 PM, "Niebel, William (wdn5e)" <wdn5e at eservices.virginia.edu>
 wrote:

> Hi, Matt.
>     We're working on this problem also at the University of Virginia.
> 
>     You said "A number of responders in Sakai-dev mentioned a few solutions that have been successful."  This makes me think I might be missing something in this thread so far.
> 
>     Running SSL between load-balancer and Sakai server certainly counts as one solution.  Am I missing any other solutions that have been mentioned?  (I think in saying "a few", you weren't counting your own solution of using front-end rewrite rules.)
> 
>     Supplying either property, sakai.force.url.secure or force.url.secure, is not a solution, because, at least with kernel 1.3.1 and Sakai 2.9.1, redirects aren't conditioned on either of those properties.  (I know about how Sakai code mirrors one of these property's value to the other.)
> 
>     And Sakai redirects seem to be one cause of the Chrome 30 problem.  We especially see that tools using CARET WebappToolServlet send redirects which trigger Chrome's http/s block.  I think there are also instances which don't involve that framework.
> 
>     We prefer to fix the Sakai code so that it works with Chrome 30, without running SSL between the load-balancer and Sakai server (as stated in the thread), and without adding rewrite rules above/outside Sakai, that is, rewrite rules in the load-balancer, webserver, or servlet container (as you're doing).  But I don't want to waste time fixing the code if someone else already has done it that way.
> 
>     Anyway, it would help me to know if there are solutions already which fix Sakai code to work behind an SSL load-balancer and non-SSL (webserver and) servlet container.
> 
> Thanks for your help.
>     Bill
> 
> 
> Bill Niebel
> University of Virginia