Exception message from Headers uses Arabic-Indic numerals for character position in some Arabic locales

[efung]

Problem

When there is an invalid character in an HTTP header set via Headers.Builder, the exception that is thrown indicates the position of the offending character using Hindu-Arabic numbers when the locale is ar_EG, Arabic (Egypt).

e.g.
java.lang.AssertionError: Unexpected char 0x668 at ٢٥ in header value: Custom Http Client 1.0.0/٨

Since the exception message itself is in English, I would expect any numeric values to be displayed in Western Arabic numbers.

Details

For some locales with the Arabic language, Android will default to displaying numbers using Arabic-Indic numerals when you use code like String.format("%d", 3)

I tested this with okhttp-2.5.0 on desktop JVM as well as Android 6.x and 4.1.2, but the same formatting code exists in okhttp-3.

Test case

Note that I was unable to reproduce the behaviour using javac 1.8.0_60 on Mac OS X, and only on Android. It's possible the locale implementations differ for ar-EG:

public final class HeadersArEgTest {
  @Test public void logMessageWithHinduArabicNumbers() {
    final Locale oldLocale = Locale.getDefault();
    final Locale newLocale = new Locale("ar", "EG");
    final String USER_AGENT = "Custom Http Client 1.0.0/٨"; // final character is invalid
    try {
      Locale.setDefault(newLocale);
      Headers headers = new Headers.Builder()
        .set("User-Agent", USER_AGENT)
        .build();
    } catch (IllegalArgumentException e) {
      String msg = e.getMessage();
      assertTrue(msg, msg.contains("at " + (USER_AGENT.length()-1) + " in header value"));
    } finally {
      Locale.setDefault(oldLocale);
    }
  }
}

[JakeWharton]

This seems like an application bug, not an OkHttp bug.

HTTP requires ISO-8859-1 for header values but it's effectively just ASCII. If you are creating a user agent using String.format then you should pass a Locale as the first argument which will ensure it renders to ASCII (such as Locale.US).

[swankjesse]

I think the problem is that OkHttp assumes that %d will return a ASCII digit and it doesn’t. I didn’t know that was possible, and it suggests we probably want %s wherever we’re currently using %d. Ugh!

[JakeWharton]

Oh this report is about the exception message itself. Got it.

[swankjesse]

We want to replace calls like this:

throw new IllegalArgumentException(String.format(
      "Unexpected char %#04x at %d in header name: %s", (int) c, i, name));

with calls like this:

throw new IllegalArgumentException(String.format(Locale.US,
      "Unexpected char %#04x at %d in header name: %s", (int) c, i, name));

[efung]

Yeah, it was a surprise to me too. But the usage of localized decimal digits is buried in java.util.Formatter:

Number localization. Some conversions use localized decimal digits rather than the usual ASCII digits. So formatting 123 with %d will give 123 in English locales but ١٢٣ in appropriate Arabic locales, for example. This number localization occurs for the decimal integer conversion %d, the floating point conversions %e, %f, and %g, and all date/time %t or %T conversions, but no other conversions.