felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konrad Windszus (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5309) SslFilter: sendRedirect does not support protocol changes on the current host
Date Wed, 20 Jul 2016 13:00:25 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15385808#comment-15385808

Konrad Windszus commented on FELIX-5309:

Since the same logic for rewriting is being used for {{sendRedirect(<some uri>)}} and
{{setHeader("Location", <some uri>)}} it is not easy to come up with a fix, which does
not break intended rewriting. What again is the reason that {{setHeader(...)}} is overwritten
as well? Even for Jetty it should work with {{sendRedirect(...)}} only because that one will
call the Jetty implementation of sendRedirect already with the correct value (i.e. rewritten

> SslFilter: sendRedirect does not support protocol changes on the current host
> -----------------------------------------------------------------------------
>                 Key: FELIX-5309
>                 URL: https://issues.apache.org/jira/browse/FELIX-5309
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: http.sslfilter-1.0.6
>            Reporter: Konrad Windszus
> Consider the case where application A and B are running under the same domain example.com.
A is served by an Apache Felix (below https://example.com/A) and only supports HTTPS (being
terminated e.g. by a LoadBalancer in front). B is served by some other application server
(below https://example.com/B) and only supports HTTP.
> Now I create a link from A towards B with {{HttpServletResponse.sendRedirect("http://example.com/B/somepath")}}.
> This URL is automatically converted by the SslFilter to {{https://example.com/B/somepath}}
which is clearly not intended.
> I think the sendRedirect(...) implementation of the SSLFilter from FELIX-4420 is way
too aggressive, because it will also rewrite absolute URIs already containing a scheme.
> Actually absolute URIs should never been rewritten by that filter, only relative ones
(starting with a "/").

This message was sent by Atlassian JIRA

View raw message