Saturday, February 27, 2016

Re: empty request object

I was referring to the wrong release notes. The rights one can be found in the 1.8 release notes in the miscellaneous section[1]:

HttpRequest now has a simplified repr (e.g. <WSGIRequest: GET '/somepath/'>). This won't change the behavior of theSafeExceptionReporterFilter class.

Printing the request in your debugger is nothing more than calling repr on the request and displaying the result. The conclusion is the same: the request is not empty, but the string representation of the request has changed. This is unrelated to whatever issue you're facing. 

[1] https://docs.djangoproject.com/en/1.9/releases/1.8/#miscellaneous

On Saturday, February 27, 2016 at 11:21:18 PM UTC+1, Larry....@gmail.com wrote:
On Sat, Feb 27, 2016 at 5:14 PM, knbk <marte...@gmail.com> wrote:
> The `__repr__` method on HttpRequest was simplified in 1.9[1]. It is not an
> accurate description of what is actually contained in the request, and I
> doubt it has anything to do with the actual issues you're facing.
>
> [1]
> https://docs.djangoproject.com/en/1.9/releases/1.9/#httprequest-details-in-error-reporting

I am printing the request object from the debugger:

(Pdb) request
<WSGIRequest: GET '/'>

This is not in the debug page. I'm pretty sure it's empty as when I
call login(request) I get a blank page with a 200 back.

>
> On Saturday, February 27, 2016 at 11:09:28 PM UTC+1, Larry....@gmail.com
> wrote:
>>
>> On Sat, Feb 27, 2016 at 5:02 PM, James Schneider
>> <jrschn...@gmail.com> wrote:
>> >
>> > On Feb 27, 2016 1:55 PM, "Larry Martell" <larry....@gmail.com> wrote:
>> >>
>> >> Anyone have any insights on this? Is there anything special I need to
>> >> do get the request structure? The way this 1.9 site is now, it doesn't
>> >> work at all because the request structure is not getting passed in.
>> >>
>> >
>> > I'd be most suspicious of middle ware not handling the request
>> > correctly.
>>
>> I tried removing all the middleware, but I got the same result. This
>> is the middleware that was in place:
>>
>>     'django.middleware.security.SecurityMiddleware',
>>     'django.contrib.sessions.middleware.SessionMiddleware',
>>     'django.middleware.common.CommonMiddleware',
>>     'django.middleware.csrf.CsrfViewMiddleware',
>>     'django.contrib.auth.middleware.AuthenticationMiddleware',
>>     'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
>>     'django.contrib.messages.middleware.MessageMiddleware',
>>     'django.middleware.clickjacking.XFrameOptionsMiddleware',
>>     'django.middleware.security.SecurityMiddleware',
>>
>>
>> > Have you tried moving to a fresh venv to ensure Django and other
>> > packages
>> > aren't damaged?
>> >
>> > Can you replicate the issue on a separate test server?
>>
>> No, I haven't tried either one yet. I guess I will have to do that,
>> but I really would like to just get this setup working.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/890bb238-7980-4b12-bdf2-400379b31ee7%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3e31049c-82cc-4587-bb18-c06e683e65a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment