On Mon, May 2, 2011 at 7:45 AM, Robert Cross <blueb...@gmail.com> wrote:
> I'm a Django newbie and I'm trying to do some minor tests with POST methods
> (I need an automated/scriptable way to get data into my Django database).
> Using the following code
>
> @csrf_exempt
> def posttest(request):
> z=request.POST.get('data', 'no data')
> html="<html><body><h1>POST Test</h1><p>Data supplied was \""
> html=html+z
> html=html+"\"</P></body></html>"
> return HttpResponse(html)
>
> When I run a test upload it fails:
>
> $ wget --post-data 'data=Something'
> http://localhost:8000/posttest?data=Command
> Line
> --2011-05-02 15:30:03-- http://localhost:8000/posttest?data=CommandLine
> Resolving localhost (localhost)... 127.0.0.1
> Connecting to localhost (localhost)|127.0.0.1|:8000... connected.
> HTTP request sent, awaiting response... 500 INTERNAL SERVER ERROR
> 2011-05-02 15:30:03 ERROR 500: INTERNAL SERVER ERROR.
>
> If I don't supply any post data then it appears to work (301 followed by
> 200 codes, but still gives the expected html).
>
> Any ideas what I'm doing wrong? (Get methods seem to work - but I'd prefer
> not to use them because they're not technically correct for a DB update
> function)
>
>
I'm not sure where the 500 error is coming from -- if you can get wget to
show you the HTTP response, then you should be able to see the actual error
and traceback in there (as long as you have DEBUG enabled, you should get
back a formatted HTML document with the error message in it)
If you can't get the error output, then try at least printing the html
variable before the view function returns. You'll at least know if if gets
that far, or if the error is happening somewhere else. Just watch the
console where your server is running, and you should see the output of any
print statements.
The fact that, on GET, you are getting a 301 first means that the URL that
you are providing is not the correct one for the resource. You probably have
"/posttest/" defined in your urls.py, but you are using wget to access
"/posttest" (no trailing slash). On a GET request, it is perfectly safe to
just issue a redirect to the correct URL, but it is not necessarily safe for
POST requests. I believe that Django will issue the redirect anyway, buy the
user agent is *not* supposed to just blindly post the data to the new URL
without some sort of user interaction.
To eliminate this as a possible error source, try putting the trailing "/"
on the URL in the command line:
$ wget --post-data 'data=Something'
http://localhost:8000/posttest/?data=CommandLine
Then you should get { 'data': 'CommandLine' } in request.GET, and { 'data':
'Something' } in request.POST.
--
Regards,
Ian Clelland
<clell...@gmail.com>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
