HTTP input binding Body property type depends on the request body content

[AnatoliB]

When a function is invoked via an HTTP trigger, the $HttpRequest.Body property type depends on the actual request body content. For example, when the request body contains a simple string like Hello, $HttpRequest.Body will contain 'Hello' as a string. However, if the request body contains anything that could be interpreted as a syntactically valid JSON (e.g. {"Hello":"world"}), $HttpRequest.Body will contain the result of JSON deserialization (@{ Hello = 'world' } as a hashtable), even when the request explicitly specifies Content-Type: text/plain. This implicit JSON deserialization may be convenient in many cases, but will cause confusion and unexpected function behavior changes depending on the client input.

Consider following more deterministic rules, such as:

• If the request has Content-Type: application/json explicitly specified:
  • If the body contains a valid JSON, deserialize and assign the result to $HttpRequest.Body
  • If the body does not contain a valid JSON, respond with 400 (BadRequest) and don't invoke the function code
• If the request has Content-Type: text/plain explicitly specified:
  • Pass the body to $HttpRequest.Body as is, don't even verify JSON syntax or attempt to deserialize
• etc.

[JustinGrote]

It looks like a RawBody parameter is being added per this PR that probably addresses your use case where you want to avoid unexpected conversions.
#210

[AnatoliB]

@JustinGrote I agree RawBody can be used a workaround, so it is not that bad. However:

• it is not obvious for the user that this workaround needs to be applied to begin with: the user who tested the function with Hello may not be aware that the behavior on {"Hello":"world"} will be dramatically different;
• it would still be nice to have the conversion applied or not applied (implicitly but consistently!) based on the request Content-Type.

[TylerLeonhardt]

I'd prefer option 2 because the convenience is so nice in not having to specify a header when invoking via Invoke-RestMethod.

[AnatoliB]

@TylerLeonhardt What are you referring to as "option 2"?

Here is what I'm proposing:

• When the request does not have Content-Type specified, keep doing what we are doing now.
• When the request contains Content-Type, respect it:
  • Don't try to deserialize if text/plain
  • Always deserialize if application/json

[TylerLeonhardt]

Yes @AnatoliB's second option which plays along with what you're suggesting.