Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#14954 closed (invalid)

AttributeError: 'dict' object has no attribute 'status_code'

Reported by: boerni@… Owned by: nobody
Component: Uncategorized Version: 1.3-alpha
Severity: Keywords:
Cc: boerni@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Django version 1.3 beta 1 SVN-15045:

  File "[...]django/django-current/django/contrib/staticfiles/handlers.py", line 74, in __call__
    
  File "[...]django/django-1.2.3/django/core/handlers/wsgi.py", line 265, in __call__
    
  File "[...]django/django-1.2.3/django/core/handlers/base.py", line 182, in get_response
    def _get_traceback(self, exc_info=None):
  File "[...]django/django-1.2.3/django/core/handlers/base.py", line 203, in handle_uncaught_exception
    anything).
  File "[...]django/django-1.2.3/django/core/handlers/base.py", line 178, in get_response
    # Return an HttpResponse that displays a friendly error message.
  File "[...]django/django-1.2.3/django/contrib/flatpages/middleware.py", line 7, in process_response
    if response.status_code != 404:
AttributeError: 'dict' object has no attribute 'status_code'

Change History (4)

comment:1 Changed 5 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

There is some conflict between the version you mention (1.3 beta 1 SVN-15045) and what seems to be indicated by the file names (django-1.2.3). Which is it, or have you really put 1.3 beta in a directory named django-1.2.3? There is also some evidence you are running a mutant/corrupted version in that traceback, though you also seem to have edited it to snip the front off pathnames so it's hard to be sure. But there's a comment shown as the line where the transition was made from base.py line 178 to the flatpage middleware line 7, and that sort of weirdness in the traceback makes me think you are running a corrupted version.

I have verified that I can get a debug page to propery display, with flatpage fallback middleware in place, on current SVN level code. I suggest you entirely remove Django and then re-install whatever level it is you want to be running, because I think what has happened here is due to some corruption in your install.

comment:2 Changed 5 years ago by anonymous

  • Resolution invalid deleted
  • Status changed from closed to reopened

Sorry for the confusing Traceback... I checked out the current trunk and removed all pyc files. Same situation, on 1.2.3 all works fine...

Traceback (most recent call last):
  File "[...]django/django-trunk/django/contrib/staticfiles/handlers.py", line 74, in __call__
    return self.application(environ, start_response)
  File "[...]django/django-trunk/django/core/handlers/wsgi.py", line 265, in __call__
    response = self.get_response(request)
  File "[...]django/django-trunk/django/core/handlers/base.py", line 182, in get_response
    response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
  File "[...]django/django-trunk/django/core/handlers/base.py", line 203, in handle_uncaught_exception
    return debug.technical_500_response(request, *exc_info)
  File "[...]django/django-trunk/django/core/handlers/base.py", line 178, in get_response
    response = middleware_method(request, response)
  File "[...]django/django-trunk/django/contrib/flatpages/middleware.py", line 7, in process_response
    if response.status_code != 404:
AttributeError: 'dict' object has no attribute 'status_code'

comment:3 Changed 5 years ago by kmtracey

  • Resolution set to invalid
  • Status changed from reopened to closed

Sorry, but the traceback still doesn't make much sense. It shows handle_uncaught_exception calling debug.technical_500_response transitioning back into BaseHandler get_response, which doesn't make any sense and is not what the Django-included technical_500_response does. I am able to get current SVN Django to properly return debug pages, so there is something odd about your install: possibly something included among your installed apps that monkey-patches bits of Django? You don't say exactly what you are doing (not even what URL is getting processed, so I can't tell whether the uncaught exception is likely coming from some Django code like admin or your own app code) or what happens (beyond "all works fine") on 1.2.3...I'm not even sure if that means whatever URL you are trying to process here works completely fine on Django 1.2.3 or properly produces a debug page for an error in some code.

Please provide more information about your configuration (installed apps, urls) and what URL you are attempting to get (or post?). Without more information it is extremely difficult to speculate about what is going wrong: as I said, I can get the code path indicated in this traceback (handling of an uncaught exception) to work properly using current SVN code, Django is not fundamentally broken here so we need more details on what's different about your configuration to tell what is going on.

comment:4 Changed 4 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

Note: See TracTickets for help on using tickets.
Back to Top