Call to fopen() failed for '????'.

[GoogleCodeExporter]

When mod_wsgi is loading a target WSGI script file, it relies on the 'filename' 
attribute of the 
Apache request object being the location of the target file. In other words, 
'filename' is the script 
file which the URL mapped to via WSGIScriptAlias or through mapping to actual 
file via 
AddHandler.

If 'filename' is modified by mod_rewrite for some reason, but mod_wsgi is still 
triggered, then 
one may see an error such as:

[Tue Apr 08 15:56:52 2008] [error] [client 71.42.227.214] (2)No such
file or directory: mod_wsgi (pid=9604, process='', application=''):
Call to fopen() failed for 'projects-build'., referer:
https://x.x.com/trac/talent_development/

In this case the rules which caused it were:

RewriteEngine   On
RewriteRule     ^/$ /trac/ [R]
RewriteRule     \.DS_Store$ - [F]
RewriteRule ^/maven2$ /maven2/ [R]
RewriteRule ^/maven2/$ /maven2/public/ [R]
RewriteRule ^/maven2/([^/]+)$ /maven2/$1/ [R]
RewriteRule ^/maven2/([^/]+)/(releases|snapshots)/(.*) http://projects-
build:9080/archiva/repository/$1-$2/$3 [P]
RewriteRule ^/maven2/([^/]+)/(.*) 
http://projects-build:8080/archiva/repository/$1/$2 [P]

It would appear that for the proxy redirect rules, execution of a handler was 
still be passed 
through to mod_wsgi.

What was odd in this situation was that it only occurred when mod_wsgi auth 
provider hooks 
were being used. The mod_wsgi auth provider hooks don't however use 'filename' 
attribute of 
Apache request object and instead grab auth script to load from configuration 
objects.

This whole scenario was originally raised in:

  http://groups.google.com/group/modwsgi/browse_frm/thread/c93607821f505218

The reporter did find some issues with their configuration and once cleaned up 
problem went 
away, but still not known for sure whether there may still be some issue in 
mod_wsgi that may 
be adding to it.

This issue here so this isn't forgotten and as a trigger for later 
investigation of how rewrite rules 
may interfere with how mod_wsgi works.

Original issue reported on code.google.com by Graham.Dumpleton@gmail.com on 26 Apr 2008 at 4:35

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 26 Apr 2008 at 4:36

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

At this stage this appears that it might be caused by issue already noticed and 
fixed in revision 1070.

If you are seeing this problem and using older code, search for all references 
to 'temp_pool' in mod_wsgi.c and 
change it 'pool'.

Original comment by Graham.Dumpleton@gmail.com on 17 Dec 2008 at 2:15

• Added labels: Milestone-Release3.0, Type-Defect
• Removed labels: Type-Other

[GoogleCodeExporter]

This may also be cause of corruption seen in:

  http://groups.google.com/group/modwsgi/browse_frm/thread/7a7f3ad8745a0e87?hl=en

Original comment by Graham.Dumpleton@gmail.com on 22 Dec 2008 at 9:47

[GoogleCodeExporter]

Original comment by Graham.Dumpleton@gmail.com on 6 Feb 2009 at 1:53

• Changed state: Started

[GoogleCodeExporter]

Also likely causing this corruption of Python egg cache path as well.

  http://groups.google.com/group/modwsgi/browse_frm/thread/256a5b99559838ce?hl=en

Original comment by Graham.Dumpleton@gmail.com on 10 Mar 2009 at 2:52

[GoogleCodeExporter]

This was backported in 2.X branch for 2.4 in revision r1129.

Original comment by Graham.Dumpleton@gmail.com on 10 Mar 2009 at 2:55

• Added labels: Milestone-Release2.4
• Removed labels: Milestone-Release3.0

[GoogleCodeExporter]

Also possibly the cause of error message:

  "client denied by server configuration: /sites/_vhosts/wsgi/slnieckova.wsgi"

seen by some users.

This is generated by hook for WSGIAccessScript, but no chance that code can be 
called unless that directive is 
used. In fact it has to pass to multiple checks and not sure why there wouldn't 
be other error messages present.

First check is:

    if (!config->access_script)
        return DECLINED;

So, only if directive was used would it even continue. In later function called 
it has:

    if (!config->access_script) {
        ap_log_error(APLOG_MARK, WSGI_LOG_ERR(0), wsgi_server,
                     "mod_wsgi (pid=%d): Location of WSGI host "
                     "access script not provided.", getpid());

        return 0;
    }

So there is a secondary check. There has been no complaint about the latter 
message.

Whatever access_script is wrongly set to, must still be valid, as the following 
doesn't crash:

    script = config->access_script->handler_script;

After that, module loading is done based on script and interrogation of whether 
it contains appropriate named 
allow_access() function. If any of that fails, there should be various error 
messages indicating as much, but not 
seen any reports of that either.

Only way it could have only that message if if found a module and a function 
and that returned None.

More information needed on this one to say whether it is caused by this 
corruption problem.

Original comment by Graham.Dumpleton@gmail.com on 23 Mar 2009 at 11:26

[GoogleCodeExporter]

The client denied by service configuration problem will only be mod_wsgi if 
message is actually of form:

"mod_wsgi (pid=%d): Client denied by server configuration: '%s'."

Ie., not to be confused by:

"client denied by server configuration: %s%s"

generated by mod_authz_host module.

The latter is going to be because of wrong Apache configuration in not having 
appropriate Allow directives.

Original comment by Graham.Dumpleton@gmail.com on 23 Mar 2009 at 11:43

[GoogleCodeExporter]

Version 2.4 of mod_wsgi now released.

Original comment by Graham.Dumpleton@gmail.com on 11 Apr 2009 at 10:25

• Changed state: Fixed