On Mon, 2009-04-06 at 23:31 -0700, Coonay wrote:
> 
> 
> On Apr 7, 12:54 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
> > On Apr 7, 2:33 pm, Coonay <fla...@gmail.com> wrote:
> >
> > > i want to get a WebOb Request ASAP when the WSGIHandler is called,such
> > > as retrieve the SERVER_NAME and SERVER_PORT meta information from the
> > > request,my stupid idea is in the line 261 of wsgi.py that add
> > > following :
> >
> > >         server_name =  request.META['SERVER_NAME']
> > >         if ( server_name is not None and server_name.startswith
> > > ('localhost') ):
> > >             settings.DEBUG = True
> >
> > > Could you tell me how to get a  WebOb Request at first place
> > > correctlly?
> 
> Hi, Graham :
> 
> 
> "Django creates an HttpRequest object that contains metadata about the
> request. Then Django loads the appropriate view, passing the
> HttpRequest as the first argument to the view function"
> 
> My question is  how to get the  http request object at first
> place,then i can retrieve the meta
> information  such as SERVER_NAME and SERVER_PORT from the request.

It depends on how early you want to get that information. It may not
exist at the point you're trying to inject into the process. The best
way to work out how to solve your problem is to have a look at the
source. 

The WSGI handling code is in django/core/handlers/wsgi.py, which it
sounds like you've already discovered. The HttpRequest object created
there is done in the __call__ method. For the default WSGI path, Djagno
creates an instance of the WSGIRequest class, which subclasses
HttpRequest. You can see in the WSGIRequest.__init__ method how the
various attributes are populated.

It seems to me, though, that if you're trying to do something very early
in the process (certainly before middleware or views are called), you
might as well just use the normal WSGI environ that is passed to the
WSGIHandler.__call__.

However, changing settings on the fly isn't supported in Django, so
you're doing something that is possibly going to break in the future. It
turns out that, right now, changing settings.DEBUG probably has no major
unintended side-effects, but that's in no way guaranteed. As an example
of what might be a consequence here, import paths might change based on
the value of settings.DEBUG and changing the DEBUG setting wouldn't
cause reimports.

You'd do better to set something in the request instance that code which
wants to act on a per-request basis can look at to determine their
behaviour.

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

Reply via email to