1

An app thats previously worked fine has started raising "Bad Request(400)" in my app whenever using the filebrowser app. The app is set to DEBUG=True, errors elsewhere raise the expected yellow screen of doom. Diffing the settings from an older revision tells me nothing has changed there and the file settings point to correct directories which I believe rules out Django FileBrowser 400 Error as an explaination. This certainly used to work. The problem is neither the console or the error dump page which works elsewhere in my install appears , just the terse Bad Request page.

I grant this isn't enough information to debug the error itself, and frankly I don't know where to look.

Rather my question is;- when this happens, is there a way to trap it at the point it raises 400 and debug it. I use ipdb in other circumstances when I need to examine the program state, but this isn't even giving me enough information to know where to drop a breakpoint!

aditional

To avoid confusion, Debug is set to True, logging is configured to dump to console and all console shows is

[11/Mar/2015 16:58:48] "GET /admin/filebrowser/browse/?pop=1 HTTP/1.1" 400 26
Community
  • 1
  • 1
Shayne
  • 1,571
  • 1
  • 16
  • 20
  • Have you read https://docs.djangoproject.com/en/1.7/howto/error-reporting/ and especially set the `ADMINS` variable? (https://docs.djangoproject.com/en/1.7/ref/settings/#std:setting-ADMINS). Django can mail you full stacktraces on error. – dhke Mar 11 '15 at 08:57
  • 1
    That only applies when Debug is set to fault. Logging is configured to dump to console. All console gets is a bright red ;- [11/Mar/2015 16:58:48] "GET /admin/filebrowser/browse/?pop=1 HTTP/1.1" 400 26 – Shayne Mar 11 '15 at 09:00
  • Thanks, I overread the `DEBUG=True`. This is strange and you should get a full trace on error page. – dhke Mar 11 '15 at 09:02
  • 1
    It appears its a regression in base.py. See https://code.djangoproject.com/ticket/21668 – Shayne Mar 11 '15 at 09:14

1 Answers1

1

Ok I found an answer.

It appears somehow I'm triggering a "suspicious operation" (It looks like it actually IS due to Django FileBrowser 400 Error), however the error was being suppressed unreasonably. This bug ticket addresses it:

https://code.djangoproject.com/ticket/21668

And the changeset at the end fixes it (However I had to remove the status_code parameter at the end, has that been deprecated?)

If anyone has a more general answer for other instances of this occuring, I'll set yours as the accepted answer.

Community
  • 1
  • 1
Shayne
  • 1,571
  • 1
  • 16
  • 20