Right now the filter seems to assume port 80 for https - which is not the best default we can come up with. So changing this to 443 is the better option. However, is there no way to get the real port using a header? Adding a configuration seems to be the last option for me.
Carsten 2014-09-29 11:34 GMT+02:00 Jan Willem Janssen <[email protected]> : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 29/09/14 11:25, Felix Meschberger wrote: > > While you are technically correct, the request.getServerPort() > > should really reflect the port that the actual SSL terminating > > server is running on. > > > > If this is the default port (getServerPort may return -1) this > > would still be 443 and not 80. So it should probably be checked > > that we get the SSL terminator’s port right. And this is really the > > bug: The current SslFilterRequest implementation does not implement > > the getServerPort method to ensure this. > > Still, this is all based on heuristics: the code assumes the SSL > terminating server runs on the default https port. > > Wouldn't it make a lot more sense to make the SslFilter configurable > wrt what ports it should rewrite? While it requires explicit > configuration, it makes the code a lot simpler and less bug-prone? > > - -- > Met vriendelijke groeten | Kind regards > > Jan Willem Janssen | Software Architect > +31 631 765 814 > > /My world is revolving around INAETICS and Amdatu/ > > Luminis Technologies B.V. > Churchillplein 1 > 7314 BZ Apeldoorn > +31 88 586 46 00 > > http://www.luminis-technologies.com > http://www.luminis.eu > > KvK (CoC) 09 16 28 93 > BTW (VAT) NL8169.78.566.B.01 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBAgAGBQJUKSeWAAoJEKF/mP2eHDc4+NIP/1DMT+7FZLLx8VDQAqxpRdFi > 2t6fAaDR+a+0UeH0vCFgMtgMmIhdJJGUhYeIo979RNuIr7k10zhnmHVPHTx7fgGq > 9kOkooD1Yw0aGBdrfxtekiUxrAXgS2zm6m1UxS+Tp3tNdwd1kNTJgUnhjFrhtnBv > /hlaO1Qg7Eu0p9GvKZhbaa3AN1ZGmEmEgpDttNCsJzoYM9LG2gZ8FgAKh58Ojo6D > 7va7kCa0RivLjGkoagdMM6LuSe7vTwl+yhzRgf6FjXxcHgRyTWyWPf5iqO7rVOFo > zauQ1Rh3UJTB7dq8j2CCWA5b4KJnfgXK8mo0O0zDnHVRNETdGlDZu3KMPexwNjrC > d03TtbiLZGx7XZA4x8jEWDeGMxMCg+pWa8VX59BNKq/JmxDgHfj+Pv8YSjuD3htT > kUw5RNzCBM2SjLupCLqQKU5E5VQpaxjMAcpvGz/JaaamsEh5C7tdWIDuKFW1f2iS > DWJ/alhE/xrF0wcQyZt+fdBeNA6vsIZ3CI26C+LPoUe4bc20fQMdUFbMtJDYNkqN > kL0/TrKC5OkoLrgRCLqzg4r0RNQZbfA5wP7P784JfjXZclTUPIWeuyzaP0bodtt/ > 9AjawZvYcuGQBkHZMUUWr4QUJKffNosRVcwJzrBKFA/O2fAQZ7LIv0xaEAaMrxy2 > Xk/TaAfkzzrIgT8idD48 > =lRNe > -----END PGP SIGNATURE----- > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
