comparison doc/upgrading.txt @ 8177:2967f37e73e4

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.
author John Rouillard <rouilj@ieee.org>
date Sun, 08 Dec 2024 01:09:34 -0500
parents 3f0f4746dc7e
children 32aaf5dc562b
comparison
equal deleted inserted replaced
8176:736f769b48c8 8177:2967f37e73e4
147 147
148 See 148 See
149 https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes 149 https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#cookie_prefixes
150 for details on this security measure. 150 for details on this security measure.
151 151
152 Invalid accept header now prevents operation (info)
153 ---------------------------------------------------
154
155 In earlier versions, the rest interface checked for an incorrect
156 "Accept" header, "@apiver", or the ".json" mime type only after
157 processing the request. This would lead to a 406 error, but the
158 requested change would still be completed.
159
160 In this release, the validation of the output format and version
161 occurs before any database changes are made. Now, all errors related
162 to the data format (mime type, API version) will return 406 errors,
163 where some previously resulted in 400 errors.
152 164
153 .. index:: Upgrading; 2.3.0 to 2.4.0 165 .. index:: Upgrading; 2.3.0 to 2.4.0
154 166
155 Migrating from 2.3.0 to 2.4.0 167 Migrating from 2.3.0 to 2.4.0
156 ============================= 168 =============================

Roundup Issue Tracker: http://roundup-tracker.org/