Test your basic knowledge |

Django Middleware

Subject : it-skills
Instructions:
  • Answer 21 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. Adds the user attribute - representing the currently-logged-in user - to every incoming HttpRequest object. See Authentication in Web requests.






2. This method is always called, even if the process_request() and process_view() methods of the same middleware class were skipped because an earlier middleware method returned an HttpResponse (this means that your process_response() method cannot rely






3. Dictionary - Attribute - Method calls - ListIndex - It uses the first one to work using a short circuit method.






4. During the request phases (process_request() and process_view() middleware), Django applies middleware in the order it's defined in MIDDLEWARE_CLASSES, top-down. During the response phases (process_response() and process_exception() middleware), the






5. This must return an SimpleTemplateResponse (or its subclass) object. It could alter the given response by changing response.template_name and response.context_data, or it could create and return a brand-new SimpleTemplateResponse (or its subclass) in






6. To start the server






7. To produce the 'markup' or presentation of the site.






8. This is called just before Django calls the view. It should return either None or an HttpResponse object. If it returns None, Django will continue processing this request, executing any other such middleware and, then, the appropriate view. If it ret






9. Binds commit and rollback to the request/response phase. If a view function runs successfully - a commit is done. If it fails with an exception - a rollback is done.






10. This method is called on each request, before Django decides which view to execute.






11. Sends custom X-View HTTP headers to HEAD requests that come from IP addresses defined in the INTERNAL_IPS setting. This is used by Django's automatic documentation system.






12. 1) Forbids access to user agents in the DISALLOWED_USER_AGENTS setting - which should be a list of strings. 2) Performs URL rewriting based on the APPEND_SLASH and PREPEND_WWW settings. 3) Sends broken link notification emails to MANAGERS if SEND_BRO






13. Adds protection against Cross Site Request Forgeries by adding hidden form fields to POST forms and checking requests for the correct value.






14. Enables language selection based on data from the request. It customizes content for each user. See the internationalization documentation.






15. Enable the site-wide cache. If these are enabled - each Django-powered page will be cached for as long as the CACHE_MIDDLEWARE_SECONDS setting defines. See the cache documentation.






16. Enables session support. See the session documentation.






17. Tell the system to do something (ie. if statements)






18. Handles conditional GET operations. If the response has a ETag or Last-Modified header - and the request has If-None-Match or If-Modified-Since - the response is replaced by an HttpNotModified.






19. Compresses content for browsers that understand gzip compression (all modern browsers).






20. Django calls this when a view raises an exception. This should return either None or an HttpResponse object. If it returns an HttpResponse object, the response will be returned to the browser. Otherwise, default exception handling kicks in.






21. Enables cookie- and session-based message support.