Hello mod_wsgi,

i've finally had time to set up a debug environment to dig into this 
behavior.

The subrequest is made by the apache function ap_add_cgi_vars() 
(httpd/server/util_script.c:381), computing PATH_TRANSLATED environ from 
r->path_info.
With this information, i uncovered the ticket 
https://bz.apache.org/bugzilla/show_bug.cgi?id=43666, which in fact 
describes the same behavior I encountered, but with the handler cgi-script.

Note that in both cases, the behavior is noticable due to the confusing 
error log, caused by the fact that a default "denied" rule is set on '/'.

Concerning mod-wsgi, 
ap_add_cgi_vars() is directly called directly by wsgi_build_environment().
I noted that the resulting value of PATH_TRANSLATED seems wrong, at least 
in my test case :

DocumentRoot 'www/static'

<Directory />
    Require all denied
</Directory>

<Directory '${EXAMPLE_ROOT}/www/myapp/'>
    <Files wsgi.py>
        Require all granted
    </Files>
</Directory>

WSGIScriptAlias /myapp '${EXAMPLE_ROOT}/www/myapp/wsgi.py'

=> The value of environ["PATH_TRANSLATED"] in wsgi.py is 
"${EXAMPLE_ROOT}/www/static/path1/path2/" 
(instead of "${EXAMPLE_ROOT}/www/myapp/wsgi.py/path1/path2/" as i think it 
should be)

If this is accurate, i think that wsgi_build_environment() should not use 
ap_add_cgi_vars(), but compute the needed variables directly.
In fact, i've found that mod_fastcgi did exactly that, providing it's own 
function, to avoid the subrequest 
(see add_auth_cgi_vars() in 
https://opensource.apple.com/source/apache_mod_fastcgi/apache_mod_fastcgi-3/mod_fastcgi/fcgi_protocol.c.auto.html
)

Thanks,
Romain

On Tuesday, August 13, 2019 at 10:19:01 AM UTC+2, Romain A. wrote:
>
> Hello,
>
> I'm currently facing a behavior from mod_wsgi/apache that is puzzling me.
> With a WSGIScriptAlias /myapp, a request url '/myapp/subpath' seems to 
> triggers a subrequest on '/subpath', which in my case, triggers an error 
> log :
> AH01630: client denied by server configuration: <DocumentRoot>/path1
> Nonetheless, the request is then served correctly by the wsgi handler.
> Is this behavior expected ?
>
[...] 

> Has someone encoutered this behavior ?
> Maybe I'm missing an obvious configuration, but for now I'm clueless.
>
> Thanks,
> Romain
>

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/modwsgi/adec7bb1-53a2-426a-9022-c1c540258043%40googlegroups.com.

Reply via email to