okhttp: IllegalArgumentException: Unexpected char ... in header value: ... at com.squareup.okhttp.Headers$Builder.checkNameAndValue (Headers.java:295)

I get crash reports like that:

java.lang.IllegalArgumentException: Unexpected char 0x43a at 101 in header value: Mozilla/5.0 (Linux; U; Android 4.1.2; ru-ru; PMP7170B3G_DUO Build/JZO54K) AppleWebKit/534.30 (KHTML, как Gecko) Version/4.0 МобильныйSafari/534.30
    at com.squareup.okhttp.Headers$Builder.checkNameAndValue (Headers.java:295)
    at com.squareup.okhttp.Headers$Builder.set (Headers.java:275)
    at com.squareup.okhttp.internal.huc.HttpURLConnectionImpl.setRequestProperty (HttpURLConnectionImpl.java:526)
    <some 3rd library code I don't have access to>

Seems to happen due to non-ASCII chars in header value. Similar to #1998. But #1998 is about response header and my smacktrace is about request header.

Thank you!

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 40 (8 by maintainers)

Commits related to this issue

Relax validation of HTTP header values to retain L/M behavior This relaxes some validation logic newly introduced in the version of OkHttp used in N. This change leaves the character code validation... — committed to NamelessRom/android_external_okhttp by nfuller 8 years ago
Reapply: Relax validation of HTTP header values to retain L/M behavior This reapplies AOSP commit 3c28a1372bd9090bed083f9212369b2b76f99ace There is a chance that we may want to revert this change in ... — committed to NamelessRom/android_external_okhttp by nfuller 8 years ago
Relax validation of HTTP header values to retain L/M behavior This relaxes some validation logic newly introduced in the version of OkHttp used in N. This change leaves the character code validation... — committed to CyanogenMod/android_external_okhttp by nfuller 8 years ago

Most upvoted comments

I used only NO_WRAP and it seems to work at the moment. I will try to write a test case with the Base64.DEFAULT flag only.

Patrick

https://www.streetlife.com.mx powered by Alpha Wave Systems On Dec 11, 2015 15:16, “Kannan Goundan” notifications@github.com wrote:

@pbertsch https://github.com/pbertsch: What encoding does the server say you should use? Is there public documentation for the server you’re sending requests to? (Aside: OkHttp should be fine with both DEFAULT and URL_SAFE – both use only printable ASCII characters.)

— Reply to this email directly or view it on GitHub https://github.com/square/okhttp/issues/2016#issuecomment-164049334.

pbertsch on Dec 11, 2015

@rohitkum28 If you ask and self answer on stackoverflow, I’ll bump up both. 25 points right there 😃

I did ask the question on StackOverflow and now that I know the answer I added it on Stackoverflow.

rohitkum28 on Mar 31, 2020

Try this: https://square.github.io/okhttp/4.x/okhttp/okhttp3/-headers/-builder/add-unsafe-non-ascii/

swankjesse on Mar 31, 2020

Just to be clear, HTTP is a byte-oriented protocol so I’m assuming you want “Ж” to be encoded as UTF-8, which would be a two-byte sequence: 0xd0, 0x96.

Loophole: use Headers.of(...), which doesn’t seem to do any validation, though this is probably dangerous to rely on. (This only works because OkHttp’s HTTP 1 and 2 codecs encode/decode header values as UTF-8, which seems problematic in general but oh well.)

cakoose on Jun 8, 2017

Character 0x0a is newline. I’m guessing sig contains a newline at the end. The docs say you can pass in Base64.NO_WRAP to omit newlines.

For OkHttp: it might be good to quote strings in error messages so the mistake is more clear. Java string literal quoting or JSON quoting seem reasonable.

cakoose on Dec 27, 2016

Yeah, agreed. We decided to make it more strict than it was before on the expectation that most people weren’t doing this deliberately.

swankjesse on Dec 3, 2015