Error AttributeError: 'function' object has no attribute 'status_code' in 6668 version

[aaloy]

This error appears in the last trunk, it not appears in 6473 version and I don't get it in all pages.

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 278, in run
    self.result = application(self.environ, self.start_response)
  File "/usr/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 620, in __call__
    return self.application(environ, start_response)
  File "/usr/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 209, in __call__
    response = middleware_method(request, response)
  File "/usr/lib/python2.5/site-packages/django/middleware/gzip.py", line 14, in process_response
    if response.status_code != 200 or len(response.content) < 200:

[aaloy]

It seems the issue is not with http but with the cache_page decorator. The decorator worked with the previos version and does not work with the trunk versions.

This worke on version 6473

def ajax_zonas(request):
    """Get all ojects from table Provincia odrdereb by name"""
    listado = Provincia.objects.all().order_by('name')
    json = serialize('json', listado,ensure_ascii=True)
    return  HttpResponse(json, mimetype='text/javascript')
ajax_zonas = cache_page(ajax_zonas, 60)

[the daniel <danielwh@…>]

Hmm, the cache_page decorator is working for me in trunk (r6826) - are there more details to reproduce? What middleware do you have installed in what order, what's an example of a view that does work correctly, etc?

[Thomas Güttler]

No feedback since several months. Closing it, since some people said 'worksforme'.

Please reopen if problem still happens with current SVN trunk.

[Mihai Damian]

This still doesn't seem to work in the svn trunk. I get the following error:

Traceback (most recent call last):

File "G:\Python25\lib\site-packages\django\core\servers\basehttp.py", line 277, in run

self.result = application(self.environ, self.start_response)

File "G:\Python25\lib\site-packages\django\core\servers\basehttp.py", line 631, in call

return self.application(environ, start_response)

File "G:\Python25\lib\site-packages\django\core\handlers\wsgi.py", line 209, in call

response = middleware_method(request, response)

File "G:\Python25\lib\site-packages\django\middleware\common.py", line 90, in process_response

if response.status_code == 404:

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

I use cache_page in urls.py. Using @cache_page in views seems to work though (or at least no errors were generated).
I have the following middleware set:

MIDDLEWARE_CLASSES = (

'django.middleware.cache.CacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',

)

I couldn't determine if CacheMiddleware was needed for individual views or not so I've tested with and without it, with the same result.

[Ramiro Morales]

@MihaiD: I have been able to reproduce the problem by using cache_page in the URLconf as you describe but by using the string syntax for the view being "decorated" instead of the callable syntax (see ​http://www.djangoproject.com/documentation/release_notes_0.96/#urlconf-improvements). This confuses django.utils.decorators.decorator_from_middleware() than then ends pushing a stub function as a decorator/middleware method parameter in a place where a HttpResponse is expected.

import views

urlpatterns = patterns('',
    (r'^foo/$', cache_page('myproj.myapp.views.myview')), # This is WRONG
    (r'^foo/$', cache_page(views.myview)), # This is OK
)

Can you confirm this is what you are doing in your setup?. If so, I will then change Component field of this ticket to Documentation and will submit a patch against the URL dispatcher docs to clarify this.

[Mihai Damian]

Yep, that's what I was trying to do. Work's fine with the second syntax you wrote

[Ramiro Morales]

The OP didn't provide enough information so we can't say for sure if the problem is the same one that got diagnosed (other possible causes could have been some bugs the decorator from middleware stuff had that were ​polished as time passed), but a a second reporter with the same symptoms did. He was using a decorator in a wrong way. Closing this ticket and opening #6832 to clarify the usage case description in the documentation.