wsgiref - When does the complexity of question require posting to the Developers or other forums?

[NoviceSortOf]

Hi All,

After hours of looking for solutions, here on Stackoverflow, GitHub, Django site and other forums,
and seeing that at least 2 other posts related to what per web chatter appears to be a known

bug in Django and the WSGI package, I'm wondering where to turn for useful advice

regarding what appears to be a common problem without a common answer.

Below is detail of a wsgiref issue that gets considerable discussion online with

no answer to the question being posted here or elsewhere.

* Should I attempt posting this question in the Developers Conf?

* Are there other forums that might be of help?

Please advise 

Details of well known Wsgiref bug/issue follow.

*******************************************************************************

After porting my project to the new development area...

When running... 

 python manage.py runserver 0.0.0.0:8000

And then loading a page on a browser I get the following.

********************************************************************************

  File "/usr/lib64/python2.7/wsgiref/simple_server.py", line 33, in close

   self.status.split(' ',1)[0], self.bytes_sent

   AttributeError: 'NoneType' object has no attribute 'split'

********************************************************************************

This problem points to the wsgi component of the install packages.

Researching the web various solutions are posted, including ...

----------------------------------------------------------------------------------

* Commenting out line 33 in simple_server.py and see if any missing

   packages are reported.

   (I've tried this and no packages are reported as missing)

REF.:  https://groups.google.com/forum/#!topic/django-users/Cps4kHh0_-0

-----------------------------------------------------------------------------------

-----------------------------------------------------------------------------------

* A Django bug report, with code that does not match the version I currently

  am using. It recommends modifications to file  

  django/core/handlers /exception.py 

  which does not exist on the release currently installed.

REF.: https://github.com/django/django/commit/742ea51413b3aab07c6afbfd1d52c1908ffcb510

------------------------------------------------------------------------------------

* A Django modification that makes perfect sense and partially matches the revision of django/core/handlers/base.py on my installed system.

REF.: https://github.com/django/django/commit/2f615b10e6330d27dccbd770a4628200044acf70

-------------------------------------------------------------------------------------

Still though I continue to get 'NoneType' object has no attribute 'render' or

other errors related to NoneType assigned as NoneType object when it should

be a request response object.

*** What to do?

* This appears to be a bug noted in Django, Github and Stackoverflow communities,

  with Wsgi related to various versions of Django and Python 

  

  _Is there any logical way of resolving the NonType error, by settings.py or other

   Django config options?

  

  _Would placing my app as the home page on this development server rather than 

   relying on the python manage.py runserver possibly resolve this problem?

  

  _Is there an alternative to Wsgi that would possibly eliminate the problem?

  

Any ideas or suggestions appreciated.

  

  

  

[Daniel Roseman]

It seems pretty unlikely that there is a fundamental bug in Django which means it cannot serve pages via WSGI; I would imagine that that would have been noticed by others, including the core developers, before now.

So it is almost certain that the bug is in your code, which you have not shown. You also need to show the full traceback.

--

DR.

[NoviceSortOf]

Thanks for the reply.

I agree the probability of this being a bug in Django is improbable still I found git hub django 

bug descriptions/discussions which URLs are listed in previous posts. Both of those URLs

listed patches to fix the situation, not directly in Django but in the WsgiRef component. 
https://github.com/django/django/commit/2f615b10e6330d27dccbd770a4628200044acf70
https://github.com/django/django/commit/742ea51413b3aab07c6afbfd1d52c1908ffcb510

I naturally referred to them being as could not find after search of the internet or this forum any further info.

It would be better if traceback pointed to my code but instead Traceback now points to 

/usr/lib/python2.7/site-packages/django/core/handlers/base.py

with the same attribute error. 'NoneType' object has no attribute 'render'.
(SEE Traceback below)

With so much of this troubleshooting being in finding the right question. 

* Would issue perhaps be limited to Django’s built-in development server?

* Would using a difference Web Interface Gateway solution solve the problem?

Details follow...

Please advise  


I type on the Linux server command line....
# python manage.py runserver 0.0.0.0:8000

then point my browser to...
http://[MyDevelopmentServerIP]:8000/

And get the following response.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Environment: Request Method: GET Request URL: http://MyServer:8000/ Django Version: 1.6.12 Python Version: 2.7.5 Installed Applications: ('django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.admin', 'django.contrib.humanize', 'django.contrib.redirects', 'bookstor.books', 'bookstor.registration', 'bookstor.profiles', 'django_extensions', 'django.contrib.admin', 'bookstor.cart') Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.transaction.TransactionMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.contrib.redirects.middleware.RedirectFallbackMiddleware') Traceback: File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 94. response = response.render() Exception Type: AttributeError at / Exception Value: 'NoneType' object has no attribute 'render'

[Matthew Pava]

For what it’s worth, I do get this error sometimes when I am running the development server, even in Python 3.5 and Django 1.10.  But because it’s the development server, I simply disregard it.

I typically only get this message when I am running several AJAX calls very close together.  (e.g. When I am filling out an autocomplete that queries the server after every key press.)

 

Seeing the error message, though, I wonder if it would be so hard to simply check if self.status is None before executing the command.

--
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/2bcd4d79-3b7e-4cb6-bac2-0778f308b666%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[NoviceSortOf]

...Thanks everyone for the above discussion -- some progress today has been noted...

To answer Matt's question...

The variable at the root of the error appears to be -- response.
as found in /usr/lib/python2.7/site-packages/django/core/handlers/base.py line 89

response is assigned as "None" in the code, before being passed to the middleware method.

The patch I found on github recommended adding these lines to base.py at line 94.
#                response = response.render()
#                response_is_rendered = True
Now mysteriously enough when commenting those lines out.
and loading devel server URL via port 8000...
I get a TemplateDoesNotExist at / index.html.

NOW ! -- That is an issue I can far more easily debug.

Also I've found out in the last half hour with the development server issuing...

# python -Wall manage.py runserver 0.0.0.0:8000

provides more granular details regarding depreciated components, a big help.

Thanks Matt & Daniel,

While I'm not completely out of the woods yet with this port/upgrade at least I'm moving towards someplace
where traceback is pointing more and more to 'my' code, which if I coded it I can more easily update/mod/fix.

Otherwise if anyone can point me to information, guides, blogs on porting from 1.1 to 1.6 please let me know. I've already reviewed the depreciation memos on the Django site from 1.1 to 1.6, and made note of relevant changes, but further materials could help.

Thanks

To post to this group, send email to djang...@googlegroups.com.

[Derek]

This may be "off topic" - so feel free to disregard! - but why "blogs on porting from 1.1 to 1.6"?  If you are in the process of upgrading, then why not keep going to at least 1.8, which is the oldest version still receiving patches and support?

Some blogs are:

* https://www.caktusgroup.com/blog/2014/07/07/tips-upgrading-django/
* http://blog.truantibexes.com/2016/01/19/2-5-years-5-developers-1-django-upgrade/
* https://www.seedinvest.com/labs/backend/upgrading-from-django-1-4-to-django-1-7
* http://andrewsforge.com/presentation/upgrading-django-to-17/ (Massive  4 part series ... assume you want to keep going beyond 1.6)

[NoviceSortOf]

On 12/5/2016 7:44 AM, Derek wrote:
>
> This may be "off topic" - so feel free to disregard! - but why "blogs on porting from 1.1 to 1.6"?  If you are in the process of upgrading, then why not keep going to at least 1.8, which is the oldest version still receiving patches and support?

Not off topic at all and much appreciated -- and also I'm making notes of your upgrade pages.

I was advised by the host provider EAPPS to go to 1.6, this is the version they installed.
Rather than rock the boat I started with the version they had for the Centos 7 package
they offered.

BACKSTORY
---------
Part of me would definately prefer a more Django friendly or knowledgeable tech support,
as our system admin tasks only require Django maintenance every few years.

My pre-sales technical questions/reachout to A2, Linode, django europe
(all providers who advertise better django support - received no replies at all.)

EAPPS on the other hand -- admitted while they were not claiming to be Django/Python experts they would
install Django and provide 7/24 support regarding Apache, mapping, help with collecting/navigating
errors during install/migration/troubleshooting and other webserver/hosting questions,
(which they have in the last 2 weeks with good results).

EAPPS techs are well versed in Java, PHP and other languages and java and drupal platforms,
they flirted with Django support a few years back but have found their marketshare apparently
in Java (their premier claim to support) and lately added Drupal.

What is unique though is that EAPPs techs are not intimidated by python or Django questions...
...provided the questions are presented in a way that relates to platforms in general, ie. mapping,
postgresql, DB setups, backup, restore and maint, Apache, WSGI and so on...

I'd love to simply have a provider who could do do the upgrades and migrations with
Django and Python, but per monthly cost doubt if the bandwidth, and other resources
cost/value could approach EAPPS.

Previously our production server was on Verio (years ago a king or minor prince of
host providers) whose service and support turned into being one of the worst
hosts imaginable. They recently have sold their hosting business to a
multinational who appear to be working the low fruit of the marketplace,
while unloading more demanding hosting requirements/clientele.

Eapps has been our development and backup server for years, previously they hosted
and supported our production JAVA based system with top level support and service. Their techs
are pro-active, their ticketing system well within par.

My search so far though for the comparative features/price I get with Eapps I've
yet to find any other Hosting provider.

We remain very open to suggestions to Django friendly providers, and am mystified
why the above mentioned companies do not answer pre-sales technical questions.

Now I suppose once we get this instance complete, we should move forward to 1.8,
time and resource providing. Moving from 1.1 to 1.6 and Redhat/Linux 2.7 to
Centos 7 on a new server has not been trivial, likely moving to 1.8 will be much easier.

Thanks all for your comments and discussion.