HTTP 500 error in apache but not in test server

59 views
Skip to first unread message

Mark Underwood

unread,
Jan 24, 2010, 8:54:19 PM1/24/10
to Django users
Hi all,

Ive already posted a lot of information here
http://serverfault.com/questions/103480/http-500-error-from-post-reuqest-to-django-vai-wsgi-and-apache
all the logs etc. so i figure i wont post it all again. But its come
down to ive got a view that takes a POST request, with a username and
password and validates it and if correct sends a http 200 back. This
works in the test server but when i deploy it using apache2, mod_wsgi
on ubuntu 9.10 and ubuntu 8.04 it returns a http 500 error. The django
debug page is posted below.Environment:

Request Method: POST
Request URL: http://bertha.homeunix.org:3000/radiobusi/auth/post_authentication_api
Django Version: 1.1.1
Python Version: 2.6.4
Installed Applications:
['django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'django.contrib.flatpages',
'mysite.polls',
'mysite.RadioBusi',
'mysite.Support',
'mysite.users']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware')


Traceback:
File "/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/
django/core/handlers/base.py" in get_response
92. response = callback(request, *callback_args,
**callback_kwargs)

Exception Type: TypeError at /auth/post_authentication_api
Exception Value: post_authentication_api() takes exactly 2 arguments
(1 given)


my code is

def post_authentication_api(self, request):
if request.method == 'POST':
print request
user = authenticate(username=request.POST['user'],
password=request.POST['pass'])
if user is not None:
if user.is_active:
print "correct"
return HttpResponse("correct", mimetype="text/plain")
else:
print "disabled"
return HttpResponse("disabled", mimetype="text/plain",
status=401)
else:
print "incorrect"
return HttpResponse("incorrect", mimetype="text/plain",
status=401)

So im not really sure what im doing wrong. My test code is


url = 'http://testserver.com/auth/post_authentication_api'
values = {'user' : 'e_username',
'pass' : 'e_password',}

data = urllib.urlencode(values)
req = Request(url, data)
print req.get_full_url()
try:
response = urlopen(req)
except URLError, e:
print e.code
print e.read()
exit()

the_page = response.read()
print the_page

the thing that is puzzling me (apart form how to fix it) is that the
test server (ie manage.py runserver) works fine, but as soon as i
deploy it it comes back with this error.

Any help would be great. And if more information is needed just let me
know.

Cheers

Mark

Graham Dumpleton

unread,
Jan 24, 2010, 9:43:47 PM1/24/10
to Django users

On Jan 25, 12:54 pm, Mark Underwood <underpl...@gmail.com> wrote:
> Hi all,
>

> Ive already posted a lot of information herehttp://serverfault.com/questions/103480/http-500-error-from-post-reuq...

This doesn't match what you posted on ServerFault. When you posted
there you had:

def post_authentication_api(request):

If you really do have a 'self' first argument for a function which
isn't a method of a class, it is obvious you are going to get:

Exception Type: TypeError at /auth/post_authentication_api
Exception Value: post_authentication_api() takes exactly 2 arguments
(1 given)

as you indicated on ServerFault.

Have you tried dropping the 'self' argument?

Graham

Mark Underwood

unread,
Jan 24, 2010, 10:35:31 PM1/24/10
to Django users
wow. thats totally my bad. Sorry graham that ive lead you on a chase
on whats going wrong. I pretty much knew it was something I had done.
Just not experienced enough to work it out. As it turned out, once i
got past that little hurdle (which im pretty sure i introduced at some
point) i got to what i think was the original issue which is that wsgi
by default blocks sys.stdout. and I had some print statements for
debugging what happened, and this was causing the internal server
error.

thank you once again Graham for all your help. You have been tireless
and very helpful with somebody who, in the end it turns out made some
silly mistakes.

Cheers

Mark

On Jan 25, 10:43 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

Graham Dumpleton

unread,
Jan 24, 2010, 11:10:51 PM1/24/10
to Django users

On Jan 25, 2:35 pm, Mark Underwood <underpl...@gmail.com> wrote:
> wow. thats totally my bad. Sorry graham that ive lead you on a chase
> on whats going wrong. I pretty much knew it was something I had done.
> Just not experienced enough to work it out. As it turned out, once i
> got past that little hurdle (which im pretty sure i introduced at some
> point) i got to what i think was the original issue which is that wsgi
> by default blocks sys.stdout. and I had some print statements for
> debugging what happened, and this was causing the internal server
> error.

Upgrade to mod_wsgi 3.1 and you will not have to deal with that
restriction on sys.stdout as I gave up trying to get people to write
portable WSGI code. People just couldn't be bothered to do it the
correct way and use sys.stderr directly. In worst case, some people
were replacing both sys.stdout and sys.stderr with a file object
opened on '/dev/null', not understanding they were actually throwing
away all their logging. Then they would complain that when an error
did occur, they couldn't find any information about it. Shakes head. :-
(

Read:

http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html

Anyway, we worked it out eventually. Do try though to be precise when
posting code snippets, configuration and log file output as having the
right information at the outset will always save time. :-)

Graham

Reply all
Reply to author
Forward
0 new messages