Request origin could not be validated. How to disable.

51 views
Skip to first unread message

Graham Dumpleton

unread,
Sep 20, 2010, 7:45:58 PM9/20/10
to modwsgi
This message is in response to:

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

Nikolai Prokoschenko

unread,
Sep 30, 2010, 7:39:05 AM9/30/10
to modwsgi
Greetings group, hello Graham, I hope you had a good holiday,

On Sep 21, 1:45 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> This message is in response to:
>
> http://stackoverflow.com/questions/3753352/why-does-django-mod-wsgi-c...

I am the original author of that question and have been onto this
problem for several weeks now.

To repeat the problem including recent findings: my production server
running SuSE Linux Enterprise 11 with Apache 2.2.14 with mod_wsgi 2.5
is throwing "Request origin could not be validated." (resulting in an
internal server error) at me almost at random. It only happens with
HTTPS, and is not application-dependant (the echo application below
also crashes). Virtually the same systems for testing and integration
testing do not expose this error. The crashes depend heavily on the
URL lengths, on the client certificates I use and also whether the
"Cache-control: no-cache" header is given or not. Each client
certificate results in different failing URL lengths, some of them
have several dozens of failings, other have barely one of two. The
problem only happens in daemon mode, however independent of the
threads and process settings (i.e. fails also with 1/1).

> 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.

Now I've got a cloned production server for a couple of days which I
can debug. I've setup the echo application and added requested
debugging information into mod_wsgi.c. The echo application doesn't
get to producing any output in failing states, it only raises the
internal server error.

The normal requests produce the following:

[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15526): MAGIC :
6f192bc86f1e8ee31a65e6b9a9a01662
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15526): KEY :
1681692777|/var/run/wsgi.15525.0.1.sock|/opt/application/
wsgi_monitor.py.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15526): HASH :
6f192bc86f1e8ee31a65e6b9a9a01662

The failing requests are slightly different, obviously the magic has
been corrupted.

[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15538): MAGIC :
6f192bc86f1e8ee31a65e6b9a9a016\xcapf\x7f.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15538): KEY :
1681692777|/var/run/wsgi.15525.0.1.sock|/opt/application/
wsgi_monitor.py.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15538): HASH :
6f192bc86f1e8ee31a65e6b9a9a01662
--
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15526): MAGIC :
6f192bc86f1e8ee31a65e6b9a9a016\x7f.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15526): KEY :
1681692777|/var/run/wsgi.15525.0.1.sock|/opt/application/
wsgi_monitor.py.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15526): HASH :
6f192bc86f1e8ee31a65e6b9a9a01662
--
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15538): MAGIC :
6f192bc86f1e8ee31a65e6b9a9a016\x90k\x86pf\x7f.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15538): KEY :
1681692777|/var/run/wsgi.15525.0.1.sock|/opt/application/
wsgi_monitor.py.
[Thu Sep 30 12:01:41 2010] [alert] mod_wsgi (pid=15538): HASH :
6f192bc86f1e8ee31a65e6b9a9a01662
--
[Thu Sep 30 12:01:42 2010] [alert] mod_wsgi (pid=15526): MAGIC :
6f192bc86f1e8ee31a65e6b9a9a016pf\x7f.
[Thu Sep 30 12:01:42 2010] [alert] mod_wsgi (pid=15526): KEY :
1681692777|/var/run/wsgi.15525.0.1.sock|/opt/application/
wsgi_monitor.py.
[Thu Sep 30 12:01:42 2010] [alert] mod_wsgi (pid=15526): HASH :
6f192bc86f1e8ee31a65e6b9a9a01662

I've tried to follow where the mod_wsgi.magic is set in code and added
some debugging to the generation code. The magic key obviously get
broken underway:

[Thu Sep 30 12:28:11 2010] [alert] [client xxx.xxx.xxx.xxx] mod_wsgi
(pid=17483): KEY 1 : 1681692777|/var/run/wsgi.17448.0.1.sock|/opt/
application/wsgi_monitor.py.
[Thu Sep 30 12:28:11 2010] [alert] [client xxx.xxx.xxx.xxx] mod_wsgi
(pid=17483): HASH 1 : 3465609b4f839d2e8d73089f84897945.
[Thu Sep 30 12:28:11 2010] [alert] mod_wsgi (pid=17449): MAGIC :
3465609b4f839d2e8d73089f848\xb3\x90\xb1\xc9\x7f.
[Thu Sep 30 12:28:11 2010] [alert] mod_wsgi (pid=17449): KEY :
1681692777|/var/run/wsgi.17448.0.1.sock|/opt/application/
wsgi_monitor.py.
[Thu Sep 30 12:28:11 2010] [alert] mod_wsgi (pid=17449): HASH :
3465609b4f839d2e8d73089f84897945

Grepping all uniq magic numbers from a log file, some kind of weird
pattern can be seen:

0aad276c628ff1d1607ee6f
0aad276c628ff1d1607ee6f70a0
0aad276c628ff1d1607ee6f70a0d88
0aad276c628ff1d1607ee6f70a0d8821
0aad276c628ff1d1607ee6f70a0d88D\x04\xa1\xb3\x7f
0aad276c628ff1d1607ee6f70a0d88\x04\xa1\xb3\x7f
0aad276c628ff1d1607ee6f70a0d88\x7f
0aad276c628ff1d1607ee6f70a0d88\xa1\xb3\x7f
0aad276c628ff1d1607ee6f70a0d88\xb3\x7f
0aad276c628ff1d1607ee6f70a0$\x04\xa1\xb3\x7f
0aad276c628ff1d1607ee6f70a0\x04\xa1\xb3\x7f
0aad276c628ff1d1607ee6f70a0\x7f
0aad276c628ff1d1607ee6f70a0\xa1\xb3\x7f
0aad276c628ff1d1607ee6f70a0\xb3\x7f
0aad276c628ff1d1607ee6f\xb3\x7f
0aad276c628ff1d1607ee6f\xd0b\x04\xa1\xb3\x7f
1f8be9300fa1f93e8dc0988
1f8be9300fa1f93e8dc09881361
1f8be9300fa1f93e8dc098813613\x7f
1f8be9300fa1f93e8dc09881361c70
1f8be9300fa1f93e8dc09881361c700f
1f8be9300fa1f93e8dc09881361c703\x7f
1f8be9300fa1f93e8dc09881361c70`\v>\xa73\x7f
1f8be9300fa1f93e8dc09881361c70\x7f
1f8be9300fa1f93e8dc09881361c70\x81\xa73\x7f
1f8be9300fa1f93e8dc09881361c70\xa73\x7f
1f8be9300fa1f93e8dc09881361c70\xce\x81\xa73\x7f
1f8be9300fa1f93e8dc09881361`\v>\xa73\x7f
1f8be9300fa1f93e8dc09881361\x7f
1f8be9300fa1f93e8dc09881361\x81\xa73\x7f
1f8be9300fa1f93e8dc09881361\xa73\x7f
1f8be9300fa1f93e8dc09881361\xae\x81\xa73\x7f
1f8be9300fa1f93e8dc09883\x7f
1f8be9300fa1f93e8dc0988\x7f
1f8be9300fa1f93e8dc0988\x80\xed\x81\xa73\x7f
1f8be9300fa1f93e8dc0988\x81\xa73\x7f
2bca926336de1c5469c5505589c3220e
3465609b4f839d2e8d73089f848
3465609b4f839d2e8d73089f84897945
3465609b4f839d2e8d73089f848979\x7f
3465609b4f839d2e8d73089f848979\x90\x1bM\xb1\xc9\x7f
3465609b4f839d2e8d73089f848979\x90\xb1\xc9\x7f
3465609b4f839d2e8d73089f848979\xb1\xc9\x7f
3465609b4f839d2e8d73089f848\xb3\x90\xb1\xc9\x7f
6f192bc86f1e8ee31a65e6b
6f192bc86f1e8ee31a65e6b9a9a
6f192bc86f1e8ee31a65e6b9a9a01662
6f192bc86f1e8ee31a65e6b9a9a016pf\x7f
6f192bc86f1e8ee31a65e6b9a9a016\x7f
6f192bc86f1e8ee31a65e6b9a9a016\x90k\x86pf\x7f
6f192bc86f1e8ee31a65e6b9a9a016\xcapf\x7f
6f192bc86f1e8ee31a65e6b9a9af\x7f
6f192bc86f1e8ee31a65e6b9a9a\x03\xcapf\x7f
6f192bc86f1e8ee31a65e6bf\x7f
702706d6db3a4f773568f61
702706d6db3a4f773568f613\x7f
702706d6db3a4f773568f61b313
702706d6db3a4f773568f61b3133\x7f
702706d6db3a4f773568f61b3136d5
702706d6db3a4f773568f61b3136d53\x7f
702706d6db3a4f773568f61b3136d588
702706d6db3a4f773568f61b3136d5\x7f
702706d6db3a4f773568f61b3136d5\x80\x86\xa73\x7f
702706d6db3a4f773568f61b3136d5\x86\xa73\x7f
702706d6db3a4f773568f61b3136d5\x90\xc5B\xa73\x7f
702706d6db3a4f773568f61b3136d5\xa73\x7f
702706d6db3a4f773568f61b313\x7f
702706d6db3a4f773568f61b313`\x86\xa73\x7f
702706d6db3a4f773568f61b313\x86\xa73\x7f
702706d6db3a4f773568f61b313\x90\xc5B\xa73\x7f
702706d6db3a4f773568f61b313\xa73\x7f
702706d6db3a4f773568f61\x7f
702706d6db3a4f773568f61\x86\xa73\x7f
702706d6db3a4f773568f61\xe0\x9c\x86\xa73\x7f

Obviously, the ones with 32 bytes are the correct ones, the others are
either truncated or extended or both.

Using the LoggindMiddleware, I can also see broken certificate data:

'HTTP_SSL_CLIENT_S_DN_CN': '0\x99>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '0\x9a>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '0\xce\x17\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '0y>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '3_g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '3\x1f\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '3\xffM\xad\x81\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '8\x9a>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '8\xc9(\xb2\x81\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '8\xf9\x18\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '+9\xd6\xa6\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'c_g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'c\x1f\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'c\xffM\xad\x81\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMhiasL_g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMhiasL\x1f\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMhias\x17\\g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMhias\x17\x1c\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMlai \xc6^g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMlai \xc6\x1e\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMn Arc_g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMn Arc\x1f\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMn Ar\xc6^g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': '_DOMn Ar\xc6\x1e\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': "Hb'\xb2\x81\x7f",
'HTTP_SSL_CLIENT_S_DN_CN': 'HI\x07\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'h\x8b>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'H\x9f\x17\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'h\xc0?\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'H\xc5?\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'h\xe5?\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'i\x11\x98\xf5\xe2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'i\x81n\xad\x81\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'i\xa1\xa5\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'i\xc1\xf9{o\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'i\xe1\x87\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'L_g\xa2\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'L\x1f\x85\x17\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'Pk>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'p\x14\x19\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'P\xae\x17\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'p\xb2?\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'P\xbf\x17\xa7\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'Py>\x1c\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRES1%3A\x8f8\xd6\xa6\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRES1%3A\x8f\xf8\xf3\x1b\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRESage,\x8f\xf8\xf3\x1b\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRESCo%3\x8f8\xd6\xa6\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRESCo%3\x8f\xf8\xf3\x1b\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRESdesa\x8f8\xd6\xa6\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRESdesa\x8f\xf8\xf3\x1b\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VREShori\x9b8\xd6\xa6\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VREShori\x9b\xf8\xf3\x1b\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRES_HOS\x8f8\xd6\xa6\xf2\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRES_HOS\x8f\xf8\xf3\x1b\x9e\x7f',
'HTTP_SSL_CLIENT_S_DN_CN': 'VRESH\xeb\xef\xda\x9b8\xd6\xa6\xf2\x7f',

Same goes for HTTP_SSL_CLIENT_S_DN_EMAIL and HTTP_SSL_CLIENT_S_DN_L.

It seems like it's some kind of memory corruption, therefore it's
perfectly possible that it's not a mod_wsgi issue. I'm also suspecting
weird iptables rules and ulimits -- the inquiry with other departments
(which are technically responsible for the server setup in question)
is underway. Still, any kind of input from Graham and other people
knowledgeable about Apache internals would be greatly appreciated.

Thanks!

Nikolai.

Graham Dumpleton

unread,
Sep 30, 2010, 8:17:55 AM9/30/10
to mod...@googlegroups.com
Great detective work so far.

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.
>
>

Nikolai Prokoschenko

unread,
Sep 30, 2010, 8:49:46 AM9/30/10
to modwsgi
Afraid not or at least not in a short time span. I've read the Apache
changelog though and haven't found my case amongst all the mod_ssl
problems.

Nikolai.

On Sep 30, 2:17 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> Great detective work so far.
>
> 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
>
> ...
>
> read more »

Nikolai Prokoschenko

unread,
Sep 30, 2010, 10:21:14 AM9/30/10
to modwsgi
Gotta reply to myself: out system engineers will update to 2.2.15,
since it's available from security channel.

The good news is: I've read the changelog AGAIN and found this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=48359

This bug describe the same things that I see -- corruption of
environment variables set by Apache. In cases where 'mod_wsgi.magic'
is also corrupted, a 500er internal server error occurs. Otherwise,
client certificate data is broken and until someone checks whether
data is valid, everything seems fine -- but it isn't.

Congrats to mod_wsgi for being strict with its input and output!

I have only little doubt that this error will persist after the
upgrade, if so, I'll write again. Until then -- thank you for your
help and attention!

Nikolai.

On Sep 30, 2:49 pm, Nikolai Prokoschenko <niko...@prokoschenko.de>
wrote:
> ...
>
> read more »
Reply all
Reply to author
Forward
0 new messages