[ https://issues.apache.org/jira/browse/FELIX-4420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043960#comment-14043960 ]
J.W. Janssen commented on FELIX-4420: ------------------------------------- [~chetanm]: thanks for the test case! I'm not to sure about the suggested fix, as it tightly couples the {{SslFilter}} to Jetty. I think it can be solved in a generic way by going back to the original proposed solution: override sendRedirect() (and possibly sendHeader() as well, for implementations that directly try to set redirect locations) and change the redirect URL on the fly. I already have some ideas on how to do this... > [HTTP SSLFilter] Implement sendRedirect > --------------------------------------- > > Key: FELIX-4420 > URL: https://issues.apache.org/jira/browse/FELIX-4420 > Project: Felix > Issue Type: Improvement > Components: HTTP Service > Affects Versions: http-2.2.1, http-2.2.2 > Reporter: Felix Meschberger > Assignee: J.W. Janssen > Fix For: http-next > > Attachments: FELIX-4420-jetty.patch, FELIX-4420.patch > > > The HTTP SSL Filter service implemented in FELIX-3693 supports revealing the > actual protocol used by the client side browser by inspecting a request > header and exposing the proper scheme through its ServletRequest.getScheme() > implementation if the actual server is operated behind an SSL terminating > proxy (i.e. client connects with HTTPS to proxy, proxy forwards request to > server over plain HTTP) > The HttpServletRequest.sendRedirect() method is declared to set the Location > header to the absolute redirect URL which includes the scheme. In an SSL > terminating proxy situation, the servlet container does not know about this > fact and hence uses the actual server scheme (HTTP) for the redirect instead > of the scheme used by client. > To fix this situation the SSL filter response should implement the > HttpServletResponse.sendRedirect() method to use use the client side scheme > as extracted from the request instead of the actual server request. -- This message was sent by Atlassian JIRA (v6.2#6252)