When I attempt to access particular pages of my application on the django development server, the server suddenly quits with no error message, leaving the browser with a "Error 324 (net::ERR_EMPTY_RESPONSE)"
What kind of thing could I have done in the code that would cause the development server to suddenly quit with no error messages?
The GET request that triggers the server to quit is not logged. For example, after starting the server and attempting a GET of one of the problem pages, my command line looks like this:
(mysite)01:25 PM benjamin ~/projects/mysite $ runserver
Validating models...
0 errors found
Django version 1.3.1, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
(mysite)01:28 PM benjamin ~/projects/mysite $
I'm running django 1.3.3 in a virtualenv using Python 2.6
I found this because I was encountering a similar problem. It turned out I was running out of memory. Figured I would mention it on the off chance that it helps someone.
The bus error can happen when you're trying to extend a template with another template that has the same filename and relative path.
Example
Let's say you want to use your own poll.html template for the voting app, but to reuse as much as possible, you extend from the original poll.html:
<!-- myapp/templates/voting/poll.html -->
{% extends 'voting/poll.html' %}
<!-- Trying to extend from 'voting/templates/voting/poll.html' -->
...
This will give you the bus error, because the template is extending "itself", even though that's not what you're trying to do.
Your own voting/poll.html is shadowing the original poll.html from the voting app, which will never be found
myproject/myapp/templates/voting/poll.html
myproject/voting/templates/voting/poll.html <-- you cannot extend from this
I haven't found a general solution to this, but I ran into the problem trying to customize the admin app's index.html and for that there is a solution (See below).
Customizing the "admin" app
I got the "bus error" when trying to customize the index.html in the admin app, and extending from the original admin/index.html. The solution to that specific problem is described here: How to override and extend basic Django admin templates? – you name your own admin/index.html something else, in order to extend from the original admin/index.html
Related
I work with django 1.11 and I have a problem with include at base.html.
When I work on localhost - everything is OK. The problem starts when the code goes live, on the server.
The problem is here:
{% include "pages/menu.html" %}
EDIT:
----project/
----templates/
--------pages/
------------footer.html
--------base.html
You have a misconfiguration in your project.
There are two places you can place templates:
In the app
my_project/my_app/templates/my_app/menu.html
In the global templates
my_project/templates/menu.html
It is not clear which of these you're using.
Furthermore, in production you will need to have my_project/templates located in the root of your webserver root. So, for Apache this might be something like /var/www/my_project/templates which a declaration in the Apache configs that this is where it should search for global templates.
I am trying to make sure that my site is properly protected from showing the details of the error in production.
I've been struggling with this for a while, as at beginning I understood that in order to avoid Django from showing the error (module, line of code, etc.) all that was needed was changing DEBUG from True to False in settings.py.
However, I realized that Django was still showing error details, so investigating a bit more and I came to know that the following was also needed:
TEMPLATE_DEBUG = DEBUG in settings.py
404.html and 500.htmlinside the templates folder
Is there anything else needed to make sure that the user does not get those messages?
And how does Django deal with the other kind of errors, like 400? I saw here that there are handlers for 400 and 403, but I do not understand it and I don't know if they are needed at all for a basic using case.
If DEBUG is False, Django doesn't show error details to the user. If it did in your case, the most likely explanations are either that it's not using the settings.py file you think it's using (in which case you should check the Python path, the directory from which you run manage.py, and the value of DJANGO_SETTINGS_MODULE), or that you did not restart Gunicorn/uWSGI/Apache after you made the change to settings.py (Django does not restart itself automatically in production like it does in development).
As for 400 and 403, just leave the Django defaults. If Django receives a bad request (unlikely in production, because this will usually be caught by Apache or nginx), it will call bad_request() which will just show a "400 bad request" to the user. Likewise for other errors.
I'm trying to access a Django page through a Facebook App (iframe) I made using fb.py on DreamHost and I keep getting an internal server error.
Looking in the error logs, this is what I see:
ModSecurity: Output filter: Failed to read bucket (rc 104): Connection reset by peer
I think it just has to do with the POST request. Somebody else asked about this error on a number of forums almost a year ago, to no avail:
ModSecurity: Output filter: Failed to read bucket (rc 104): Connection reset by peer
All I could find searching was this at http://www.modsecurity.org:
"When mod_security denies such a request, it sends an error bucket with e.g. code 403 down the output filter chain, leaving r->status as is (e.g. 500)."
Any ideas? Thanks!
Have you implemented CSRF protection as per https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax ?
Note to cross-check with the version of Django you are using.
So I've spent way too much time trying to figure this out. I've settled on a (slightly shitty) work-around: add {% csrf_token %} to any place in your template (I'm assuming you passed in the context_instance=RequestContext(request) argument to your render_to_response or whatever).
I think what is happening is that the cookie doesn't actually get set (this can be confirmed through inspecting the cookies in any browser's development tools). Adding the above code to your template forces this. I have a feeling that this may be remedied in later versions of Django, and it seems as though there are obvious fixes for 1.4+ (e.g., see here). Unfortunately dreamhost has stuck us with 1.2.3, so we need to make do.
asked this question over the weekend, but for some reason all replies have died. started it again as i now have new information
when i restart apache on my vps, i get
the model "category" is already registered
from init.py
i think this is because the object is getting discovered and registered twice.
i didn't think this would be an issue, it isn't in dev where i don't get these errors. also, i dont get the error the first time i run the server after a syncdb.
so upload code, syncdb, start apache, no error message. restart apache and the error message appears.
i can hide it, by commenting out the line that registers the model, but this means that the object doesn't appear in admin unless i uncomment the line and upload it after the admin site has loaded the first time.
this only appears to happen the first time after an apache reset, doesn't happen subsequent times.
anyone come across this before? using apache with mod_wsgi on debian, django 1.2.3
The error message suggests that model registration code is being repeated. Are you registering your models in the models.py file? The recommended way is to write a separate admin.py file to register the models.
This can be due to the order with which you have subclassed other models. For instance, if you subclass both Django-polymorphic's PolymorphicModel and another model, e.g., Django-extensions' TimeStampedModel, you need to subclass PolymorphicModel first or it will raise this error:
class MyClass(TimeStampedModel, PolymorphicModel): # Raises error
class MyClass(PolymorphicModel, TimeStampedModel): # Does not raise error
I started playing around with web2py the other day for a new project. I really like the structure and the whole concept which feels like a breath of fresh air after spending a few years with PHP frameworks.
The only thing (currently) that is bothering me is the ticketing system. Each time I make a misstake a page with a link to a ticket is presented. I guess I could live with that if the link worked. It currently points to an admin page with http as protocol instead of https. I've done a bit of reading and the forced https for admin seems to be a security measure, but this makes debugging a pain.
Whats the standard solution here? Alter the error page, allow http for admin och use logs for debugging?
Best regards
Fredrik
I was in the same boat as you, I did not like the default mechanism. Luckily, customized exception handling with web2py is very straightforward. Take a look at routes.py in the root of your web2py directory. I've added the following to mine:
routes_onerror = [('application_name/*','/application_name/error/index')]
This routes any exceptions to my error handler controller (application_name/controllers/error.py) in which I defined my def index as:
def index():
if request.vars.code == '400':
return(dict(app=request.application,
ticket=None,
traceback="A 400 error was raised, this is controller/method path not found",
code=None,
layer=None,
wasEmailed=False))
elif request.vars.code == '404':
return(dict(app=request.application,
ticket=None,
traceback="A 404 error was raised, this is bad.",
code=None,
layer=None,
wasEmailed=False))
else:
fH = file('applications/%s/errors/%s' % (request.application,request.vars.ticket.split("/")[1]))
e = cPickle.load(fH)
fH.close()
__sendEmail(request.application,e['layer'],e['traceback'],e['code'])
return(dict(app=request.application,
ticket=request.vars.ticket,
traceback=e['traceback'],
code=e['code'],
layer=e['layer'],
wasEmailed=True))
As you can see for non-400 and 404 errors, I'm emailing the traceback to myself and then invoking the corresponding views/error/index.html. In production, this view gives a generic "I'm sorry an error has occurred, developers have been emailed". On my development server, it displays the formatted traceback.
Normally, I just use http://127.0.0.1/ (if you are local or over ssh) or edit/navigate using https://...
So, you will logon the admin app the first time, but always will the show the tickets after.