question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Feature: Provide RequestBody.create WITHOUT default charset=utf-8

See original GitHub issue
  • Feature Request. Start by telling us what problem you’re trying to solve. Often a solution already exists! Don’t send pull requests to implement new features without first getting our support. Sometimes we leave features out on purpose to keep the project small.

There are cases where adding charset=utf-8 breaks server-side implementations, most notably, Amazon AWS Gateway API JSON model mapping.

JSON’s default encoding is UTF-8 per https://tools.ietf.org/html/rfc7158#section-8.1 so sending an “application/json” should be equivalent to “application/json; charset=utf-8”.

Proposal:

Introduce another RequestBody.create OR modify MediaType to handle contentType=“”.

And please don’t break current work-around:

public static RequestBody create(final MediaType contentType, final byte[] content

Line 46: RequestBody.java

public static RequestBody create(MediaType contentType, String content) {
    Charset charset = Util.UTF_8;
    if (contentType != null) {
      charset = contentType.charset();
      if (charset == null) {
        charset = Util.UTF_8;
        contentType = MediaType.parse(contentType + "; charset=utf-8");
      }
    }
    byte[] bytes = content.getBytes(charset);
    return create(contentType, bytes);
}

Issue Analytics

  • State:closed
  • Created 7 years ago
  • Reactions:6
  • Comments:22 (3 by maintainers)

github_iconTop GitHub Comments

20reactions
SoftwareArtisancommented, Jan 5, 2017

okHttp code would be better served by using principle of “least surprise”.

In this case, a developer sets the MediaType to NADA, feeds it to RequestBody. The “least surprising” thing is the header is set as per the developers instruction not shove a charset=XXX modifier on the header - something that is NOT required by the spec.

In any case, I’ll let the issue go.

14reactions
swankjessecommented, Jan 4, 2017

You should also ask Amazon to fix their API. Not accepting the UTF-8 charset is certainly an easy-to-fix mistake.

Read more comments on GitHub >

github_iconTop Results From Across the Web

java - RequestBody.create(contentType, content) Deprecated
It was deprecated since version 4.0.0 of okhttp3. The documentation for that version says @JvmStatic @Deprecated( message = "Moved to extension ...
Read more >
Make default charset UTF-8 when using `receiveText` for ...
Effectively I get the following error (it's not from ktor, but it might help understand what the issue with encoding is): java.lang.IllegalArgumentException: No...
Read more >
RequestBody (OkHttp 3.14.0 API)
Returns a new request body that transmits content . If contentType is non-null and lacks a charset, this will use UTF-8. create. public...
Read more >
Request and response objects - Django documentation
Returns an empty list if the key doesn't exist and default is None . It's guaranteed to return a list unless the default...
Read more >
Express body-parser middleware
This error will occur when the request had a charset parameter in the Content-Type header, but the iconv-lite module does not support it...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found