On Fri, Jul 11, 2014 at 5:09 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Fri, Jul 11, 2014 at 10:25 PM, Jeff Trawick <traw...@gmail.com> 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.
>
Thanks for looking, Yann. I did change it to use ap_is_initial_req()
(without the ! :) )
r1609914
