On Fri, Jul 11, 2014 at 10:25 PM, Jeff Trawick <[email protected]> wrote:
> A patch:
>
> Index: modules/ssl/ssl_engine_kernel.c
> ===================================================================
> --- modules/ssl/ssl_engine_kernel.c (revision 1609790)
> +++ modules/ssl/ssl_engine_kernel.c (working copy)
> @@ -164,7 +164,7 @@
>          return DECLINED;
>      }
>  #ifdef HAVE_TLSEXT
> -    if (r->proxyreq != PROXYREQ_PROXY) {
> +    if (!r->prev && r->proxyreq != PROXYREQ_PROXY) {
>          if ((servername = SSL_get_servername(ssl,
> TLSEXT_NAMETYPE_host_name))) {
>              char *host, *scope_id;
>              apr_port_t port;
>
>
> This path in the post-read-request hook is performing some SNI-related error
> checking, catching situations where it will return 400 or 403.
>
> I noticed with StrictSNIVHostCheck failures that this code is triggering an
> error on a subrequest to generate an error document after catching the same
> error on the initial request.
>
> Is there a reason either of the checks here needs to be made on a
> subrequest?

I don't see any, the post-read-request hooks are always run on the
initial request, and the SSL* will always be the one of the initial
request for all its subrequests (unless some third-party module plays
really bad with subr->connection).

You probably could use !ap_is_initial_req(r) but post-read-request
hooks are never run on ap_sub_req()uests (having r->main) AFAIK.

Reply via email to