http://stackoverflow.com/questions/3753352/why-does-django-mod-wsgi-crash-on-certain-url-lengths
Am in a rush today and no time to wait until that poster decides to
use the mailing list instead of SO. They previously raised it a while
back on #django on IRC and by chance I was on but impossible to debug
on IRC. Now they have tried SO.
FWIW, going forward, even after I come back from holidays, I am likely
to start ignoring mod_wsgi questions posted anywhere but the mod_wsgi
mailing if it is obvious that it is a user problem, especially where
the answer is in the documentation or covered by my presentation on
getting started with mod_wsgi. So, will only respond to what may look
like a genuine mod_wsgi issue or environment/configuration issue I am
not aware of. Even then, I will tell people to go use the mod_wsgi
mailing list. In short, use the mod_wsgi mailing list and you will be
okay and more likely to get a response.
Now, for this issue with getting the error:
Request origin could not be validated.
This is an error which occurs when the daemon mode process thinks
someone is trying to break in and get the daemon process to run
arbitrary code. It is part of code that ensures that requests to
handle a request are actually coming from the Apache server child
processes.
In this case it would appear the check is failing even though when
coming from Apache server child processes. It seems to be claimed that
it occurs only for specific URLs.
The code which supports this check is the very last thing done before
proxying request and the very first thing after request is received.
It is hard to see how something could stuff it.
Normally the magic environ value which is used to check origin of
request is deleted once used. To try and sort out this problem, want
to disable the check and not delete the value.
Thus, in mod_wsgi.c find code:
magic = apr_table_get(r->subprocess_env, "mod_wsgi.magic");
if (!magic) {
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(rv), wsgi_server,
"mod_wsgi (pid=%d): Request origin could not be "
"validated.", getpid());
apr_pool_destroy(p);
return HTTP_INTERNAL_SERVER_ERROR;
}
key = apr_psprintf(r->pool, "%ld|%s|%s|%s",
wsgi_daemon_process->group->random,
wsgi_daemon_process->group->socket, filename, script);
hash = ap_md5(r->pool, (const unsigned char *)key);
memset(key, '\0', strlen(key));
if (strcmp(magic, hash) != 0) {
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(rv), wsgi_server,
"mod_wsgi (pid=%d): Request origin could not be "
"validated.", getpid());
apr_pool_destroy(p);
return HTTP_INTERNAL_SERVER_ERROR;
}
apr_table_unset(r->subprocess_env, "mod_wsgi.magic");
In this code, put a #if 0/#endif around the if() checks and the
unsetting of the magic variable. Also add debug logging to dump out
calculated magic value which should be matched. Thus:
magic = apr_table_get(r->subprocess_env, "mod_wsgi.magic");
#if 0
if (!magic) {
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(rv), wsgi_server,
"mod_wsgi (pid=%d): Request origin could not be "
"validated.", getpid());
apr_pool_destroy(p);
return HTTP_INTERNAL_SERVER_ERROR;
}
#endif
key = apr_psprintf(r->pool, "%ld|%s|%s|%s",
wsgi_daemon_process->group->random,
wsgi_daemon_process->group->socket, filename, script);
hash = ap_md5(r->pool, (const unsigned char *)key);
memset(key, '\0', strlen(key));
#if 0
if (strcmp(magic, hash) != 0) {
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(rv), wsgi_server,
"mod_wsgi (pid=%d): Request origin could not be "
"validated.", getpid());
apr_pool_destroy(p);
return HTTP_INTERNAL_SERVER_ERROR;
}
#endif
#if 0
apr_table_unset(r->subprocess_env, "mod_wsgi.magic");
#endif
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(0), wsgi_server,
"mod_wsgi (pid=%d): MAGIC %s.", getpid(), magic);
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(0), wsgi_server,
"mod_wsgi (pid=%d): KEY %s.", getpid(), key);
ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(0), wsgi_server,
"mod_wsgi (pid=%d): HASH %s.", getpid(), hash);
This should mean that error does occur and values to be compared are logged.
Note that above is code from mod_wsgi 4.0. If using older version
(preferably 3.X, and if not upgrade), accommodate for differences as
necessary.
Also don't use the Django application, use echo application in:
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Displaying_Request_Environment
Ie. use:
import cStringIO
import os
def application(environ, start_response):
headers = []
headers.append(('Content-Type', 'text/plain'))
write = start_response('200 OK', headers)
input = environ['wsgi.input']
output = cStringIO.StringIO()
print >> output, "PID: %s" % os.getpid()
print >> output, "UID: %s" % os.getuid()
print >> output, "GID: %s" % os.getgid()
print >> output
keys = environ.keys()
keys.sort()
for key in keys:
print >> output, '%s: %s' % (key, repr(environ[key]))
print >> output
output.write(input.read(int(environ.get('CONTENT_LENGTH', '0'))))
return [output.getvalue()]
Capture output in browser from echo application and what is logged for
good request and for request that previously failed.
This is what I need to debug this issue.
Graham
Can you try with Apache 2.2.16 (latest), built from source code if
necessary. I do sort of recollect mod_ssl fixes in some of the latest
Apache releases.
Graham
On Thursday, September 30, 2010, Nikolai Prokoschenko
> --
> You received this message because you are subscribed to the Google Groups "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
>