Yup, no extra steps for correct behavior. I'd support a ''surpress SNI' flag, and/or an explicit SNI arg, much like openssl s_client -- just for testing. But that should be the exceptional case. On Jul 1, 2016 8:33 AM, "Reindl Harald" <h.rei...@thelounge.net> wrote:
Am 01.07.2016 um 15:23 schrieb Yann Ylavic: > On Fri, Jul 1, 2016 at 3:17 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > >> On Fri, Jul 1, 2016 at 3:02 PM, Reindl Harald <h.rei...@thelounge.net> >> wrote: >> >>> >>> Am 01.07.2016 um 14:41 schrieb Yann Ylavic: >>> >>>> >>>> The -I does not take any argument, it tells ab to use iether the -H >>>> "Host: ..." if any, or the host from the given URL otherwise >>>> >>> >>> but why is there a param needed instead just send the SNI header from the >>> given URL like any browser does? >>> >> >> You may want to use an IP (or another DNS name) in the URL and still >> reach the right (Virtual)Host on the server by specifying a -H "Host: >> ...". >> >> The -H "Host:" existed already, and if it's used it has to be taken >> for the SNI, that's how the server will elect the appropriate >> VirtualHost if multiple ones listen on the same port. >> > > Oh, I probably misunderstood your remark, you probably meant this > should be the defaut when TLS is available and used (per -f). > > Good point, will look at it > exactly - it's all present what is needed to send the host-header and in case of TLS that's just the same which is needed for the SNI header without the need to tell "ab" it should use SNI by introducing a new param
