Hi Malcolm, Thank you very much for the detailed answer! Everything is working OK now.
///Kalle On May 8, 11:53 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Fri, 2009-05-08 at 11:24 -0700,Kallewrote: > > Hi, > > > I'm just started to play with Django, and ran into this problem right > > away. > > > * I'm using the python script at the bottom to POST to the url. > > * I'm using "manage.py runserver" to run my app > > * Everything works fine when I'll run my tests with "manage.py test". > > > When I set a breakpoint at django/core/handlers/base.py:77 I see that > > request.path_info is "http://127.0.0.1:8000/uncaughtexception/drop";. > > From what I > > understand, request.path_info should be "/uncaughtexception/drop" at > > that point? > > > Since the tests works it must be some error in my setup of runserver. > > I can't understand what kind of setting I should use to make django > > strip way the host > > part of the URL. > > [...] > > > --- test script --- > > HOST = "127.0.0.1:8000" > > URL = "http://%s/uncaughtexception/drop"; % HOST > > > h = httplib.HTTPConnection(HOST) > > headers = { "Content-Type" : "text/html; charset=utf-8" } > > h.request("POST", URL, "apa", headers) > > This is where the problem lies. The URL you send to the host should not > contain the hostname and scheme. That is already implicit in the > HTTPConnection object. So your URL variable should be simply > "/uncaughtexception/drop/". > > A rough breakdown of what happens when your webbrowser (or anything > speaking HTTP) connects tohttp://example.com/foo/bar/is this: > > (1) Connection opened to example.com, port 80 > (2) Down that connection, the client sends > > GET /foo/bar HTTP/1.1 > Host example.com > ... > > (the "..." hides some extra headers that might be sent) > > Notice that the "GET" request includes the resource to retrieve. It > already knows *where* to send it because it's made a network connection. > In your case, GET becomes POST and there's a different port number > involved, etc, but the point is that single URL encapsulates multiple > operations. > > Now, all this being said, you're potentially making life a little hard > for yourself here if you're only wanting to test your views. Django > contains a little test client that simulates a browser connection, > without requiring you to run a whole separate server and so on. What > you're doing isn't necessarily wrong, but if you're unaware > ofhttp://docs.djangoproject.com/en/dev/topics/testing/#module-django.te...you > might want to have a quick play with that first. It will make your tests a > fair bit simpler. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
