mattcasters opened a new pull request, #8569: URL: https://github.com/apache/hop/pull/8569
## What REST Client no longer puts a charset parameter on `Content-Type` unless the row sets that header itself. Application type JSON was sent as `application/json; charset=UTF-8`, because that is how HttpClient renders `ContentType.APPLICATION_JSON`. The body was already UTF-8. Hop 2.17 (Jersey) sent `application/json` with no parameter. ## Why Fixes #8507. Omie (`https://app.omie.com.br/api/v1/geral/clientes/`) answers `Content-Type: application/json; charset=UTF-8` with HTTP 500 and this body: ```xml <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope";><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text>Bad Request</env:Text></env:Reason></env:Fault></env:Body></env:Envelope> ``` The same POST with `Content-Type: application/json` reaches the API. `text/xml; charset=UTF-8` produces the same fault, so every application type now sends the mime type alone. A Headers-tab `Content-Type` is still sent exactly as written, and that charset is what encodes the body. On 2.19, before this change: set a Headers field `Content-Type` to `application/json` (no charset). The detailed request log prints the entity content type first, which still shows `charset=UTF-8` even when the header that goes out does not. ## Test `RestCallRestTest` covers a JSON POST with no charset parameter and UTF-8 bytes, a header of `application/json`, a header of `application/json; charset=ISO-8859-1` (those bytes), and form-urlencoded with no charset parameter and ISO-8859-1 bytes. `RestRequestLoggingTest` asserts the detailed block does not contain `charset`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
