refactor: issue2551289. invalid REST Accept header stops request Sending a POST, PUT (maybe PATCH) with an accept header that is not application/json or xml (if enabled) used to complete the request before throwing a 406 error. This was wrong. Now it reports an error without dispatching/processing the requested transaction. This is the first of a series of refactors of the dispatch method to make it faster and more readable by using return early pattern and extracting methods from the code. changes: The following now return 406 errors not 400 errors invalid version specified with @apiver in URL. invalid version specified with @apiver in payload body invalid version specified in accept headers as application/vnd.roundup.test-vz+json or version property Parsing the accept header returns a 400 when presented with a parameter without an = sign or other parse error. They used to return a 406 which is wrong since the header is malformed rather than having a value I can't respond to. Some error messages were made clearer. Results in the case of an error are proper json error object rather than text/plain strings. New test added for testdetermine_output_formatBadAccept that test the new method using the same test cases as for testDispatchBadAccept. I intend to extend the test coverage for determine_output_format to cover more cases. This should be a faster unit test than for dispatch. Removed .lower() calls for accept_mime_type as the input values are taken from the values in the __accepted_content_type dict which only has lower case values.

Getting started:
For running the tests, you want to take a look at the documentation in
doc/developer.txt, in particular the section "Testing Notes".
For a test setup of the database backends, suitable documentation is
found in in doc/postgresql.txt for the Postgres backend, in the section
titled "Running the PostgreSQL unit tests". For the MySQL backend the
file doc/doc/mysql.txt has the documentation in section "Running the
MySQL tests".

A number of tests uses the infrastructure of
	db_test_base.py

grep "from db_test_base" -l *.py
benchmark.py
session_common.py
test_anydbm.py
test_indexer.py
test_memorydb.py
test_mysql.py
test_postgresql.py
test_security.py
test_sqlite.py
test_userauditor.py

grep "import db_test_base" -l *.py
test_cgi.py
test_jinja2.py
test_mailgw.py
test_xmlrpc.py

grep "import memory\|from memory" -l *.py 
test_mailgw.py
test_memorydb.py


The remaining lines are an 2001 description from Richard,
which probably is outdated:

Structure of the tests:

   1   Test date classes
   1.1 Date
   1.2 Interval
   2   Set up schema
   3   Open with specific backend
   3.1 anydbm
   4   Create database base set (stati, priority, etc)
   5   Perform some actions
   6   Perform mail import
   6.1 text/plain
   6.2 multipart/mixed (with one text/plain)
   6.3 text/html
   6.4 multipart/alternative (with one text/plain)
   6.5 multipart/alternative (with no text/plain)