Wow.
Digging into the issue, we realized this only occurred on specific pages, and verified that when this phone navigates to any pages served by them in its browser, these HTTP headers still appear in the body causing errors.
I wiresharked a small HTTP session today and noticed that these headers are being considered part of the body!
All the line breaks in the HTTP layer were \n\r, or LF CR.
From HTTP 1.1 RFC 2616: http://www.ietf.org/rfc/rfc2616.txt
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
protocol elements except the entity-body (see appendix 19.3 for
tolerant applications). The end-of-line marker within an entity-body
is defined by its associated media type, as described in section 3.7.
CRLF = CR LF
...
[…] a bare CR
or LF MUST NOT be substituted for CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
...
6 Response
After receiving and interpreting a request message, a server responds
with an HTTP response message.
Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
This seems like a big issue - however, the only way the app could have lasted until now appears the suggestion (19.3) that applications SHOULD tolerate a single LF.
So I guess HTC ignored this suggestion on the HTC One!! :-P
To work around this, I tried to use HttpClient (version included with Android SDK), but that also had the same problem. I wanted to try using the jar files from Apache HTTP Components, but of course those have a package name conflict with the version in the Android framework, so I repackaged them with Jar Jar Links. Once the imports were replaced with that it worked!