From 1d687339ad047984435f0c8af6188e855eefc1da Mon Sep 17 00:00:00 2001
From: Stephen Rosen <sirosen@globus.org>
Date: Sat, 23 Nov 2019 16:28:36 +0000
Subject: [PATCH] Clarify changelog for 6.0 and fix docs

Add notes to changelog about making parsers more consistent about
checking Content-Type for JSON payloads.
Refactor the 6.0 changelog to better separate into
features/refactoring/bugfixes.

Fix use of autofunction for function definition inclusion in advanced
docs: autofunction only pulls the docstring, not the full function
definition. Instead, just copy the code verbatim.
---
 CHANGELOG.rst     | 20 ++++++++++++++------
 docs/advanced.rst | 15 ++++++++++++++-
 2 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/CHANGELOG.rst b/CHANGELOG.rst
index 1ade9a25..fc0e4e08 100644
--- a/CHANGELOG.rst
+++ b/CHANGELOG.rst
@@ -4,6 +4,14 @@ Changelog
 6.0.0 (unreleased)
 ******************
 
+Features:
+
+* *Backwards-incompatible*: Schemas will now load all data from a location, not
+  only data specified by fields. As a result, schemas with validators which
+  examine the full input data may change in behavior. The `unknown` parameter
+  on schemas may be used to alter this. For example,
+  `unknown=marshmallow.EXCLUDE` will produce behavior similar to webargs v5
+
 Refactoring:
 
 * *Backwards-incompatible*: Schema fields may not specify a location any
@@ -34,17 +42,17 @@ Refactoring:
     def foo(q1, q2, h1):
         ...
 
-* *Backwards-incompatible*: Schemas will now load all data from a location, not
-  only data specified by fields. As a result, schemas with validators which
-  examine the full input data may change in behavior. The `unknown` parameter
-  on schemas may be used to alter this. For example,
-  `unknown=marshmallow.EXCLUDE` will produce behavior similar to webargs v5
-
 * The `location_handler` decorator has been removed and replaced with
   `location_loader`. `location_loader` serves the same purpose (letting you
   write custom hooks for loading data) but its expected method signature is
   different. See the docs on `location_loader` for proper usage.
 
+Bug fixes:
+
+* *Backwards-incompatible*: all parsers now require the Content-Type to be set
+  correctly when processing JSON request bodies. This impacts ``DjangoParser``,
+  ``FalconParser``, ``FlaskParser``, and ``PyramidParser``
+
 5.5.1 (2019-09-15)
 ******************
 
diff --git a/docs/advanced.rst b/docs/advanced.rst
index 4ae06de6..03b52cf1 100644
--- a/docs/advanced.rst
+++ b/docs/advanced.rst
@@ -43,7 +43,20 @@ locations.
 The `json_or_form` location does this -- first trying to load data as JSON and
 then falling back to a form body -- and its implementation is quite simple:
 
-.. autofunction:: webargs.core.Parser.load_json_or_form
+
+.. code-block:: python
+
+    def load_json_or_form(self, req, schema):
+        """Load data from a request, accepting either JSON or form-encoded
+        data.
+
+        The data will first be loaded as JSON, and, if that fails, it will be
+        loaded as a form post.
+        """
+        data = self.load_json(req, schema)
+        if data is not missing:
+            return data
+        return self.load_form(req, schema)
 
 
 You can imagine your own locations with custom behaviors like this.