CP-1939 Allow content-type to be set manually

[evanweible-wf]

Improvement

Currently every request's content-type is set automatically (with the exception of StreamedRequest) based on the request type and the encoding. This is too inflexible as there are valid use cases for wanting to override the content-type like integration with a server that expects a certain content-type.

It was requested by @stevenosborne-wf that we add support for manually setting the content-type.

Changes

• FormRequest.contentType, JsonRequest.contentType, and Request.contentType can now be set manually.

• MultipartRequest.contentType still cannot be set manually because a multipart request requires a specific content-type with a boundary string parameter.

• StreamedRequest.contentType was already overridable by consumers since the content is not known prior to opening the request. This is still the case, but I fixed a bug where we weren't verifying that the request had not yet been sent when setting the content-type.

• Previously, the content-type would be automatically updated when the encoding was changed. This is still the default behavior, but once a user manually sets the content-type, this will stop. In other words, we are assuming that a consumer who sets the content-type manually is intentionally overriding the defaults and is taking responsibility of setting the charset parameter appropriately.

• Technically, since the StreamedRequest already allowed consumers to manually set the content-type but did not enforce the behavior described in the previous point, the expected behavior of existing code could change in only this exact scenario:

  var streamedRequest = new StreamedRequest()
    ..uri = Uri.parse('/example')
    ..contentLength = 100
    ..contentType = new MediaType('application', 'octet-stream')
    ..encoding = UTF8;

  Previously, setting encoding after contentType would have triggered an update to the content-type to include a charset: utf-8 parameter, but after this change, this will no longer happen.

Testing

• CI passes (tests updated and new tests added, should be 100% patch coverage)
• Examples still work as expected

Code Review

@trentgrover-wf
@maxwellpeterson-wf
@dustinlessard-wf
@jayudey-wf
@sebastianmalysa-wf
@srinivasdhanwada-wf

fyi: @stevenosborne-wf

[maxwellpeterson-wf]

+1

[stevenosborne-wf]

Thanks!

[sebastianmalysa-wf]

+1 once conflicts are resolved

[evanweible-wf]

@maxwellpeterson-wf @sebastianmalysa-wf Rebased against latest master and fixed a conflict in CHANGELOG.md.

[maxwellpeterson-wf]

+1

[codecov-io]

Current coverage is 99.53%

Merging #153 into master will increase coverage by <.01%

Powered by Codecov. Last updated by eb7cb16...13239d4

[sebastianmalysa-wf]

+1

[evanweible-wf]

@jayudey-wf ready for merge

[jayudey-wf]

QA Resource Approval: +10

• Testing instruction
• Dev +1's
• Dev/QA +10 with detail of what was tested
  • passing CI
  • examples working as expected (noted an issue that evan has documented here, CP-2240 HttpException: Headers size exceeded the of '8192' bytes #156 )
• Unit test created/updated
• All unit tests pass

Merging into master.