The Motorola iDEN [1] series of phones were pretty sweet back in their day and had a JVM you could actually write and deploy apps on.

I worked on Loopt, an early mobile location sharing app, and we talked to our server over HTTPS. Things were working great on a few LG and Sanyo phones, and worked fine in the iDEN emulator, but POSTs would fail consistently on the device itself. GETs worked fine.

After watching traffic on the server for a bit, I noticed the POST requests all advertised HTTP/1.1 and sent the Expect: 100-Continue header. On a whim I configured the server to treat all incoming connections as HTTP/1.0 so it would never send the 100 (Continue) response [2].

It worked!

Or did it? Turns out the iDEN phones were now happy, but the other phones were not and would refuse to send POST bodies if they didn't receive the 100 (Continue).

This well and truly sucked, and we thought for a bit we'd need to have two different endpoints with different configurations to support the differently incompatible phones. Lame.

But then I remembered the format of an HTTP request:

    POST /path HTTP/1.1\r\n
    Expect: 100-Continue\r\n
    [Header: Value]\r\n
    \r\n
    [Body]

What if I supplied a malformed URL? Something like "/path HTTP/1.0\r\nX-iDEN-Ignore:"? Then, if there's no validation or encoding, the request will look like this:

    POST /path HTTP/1.0\r\n
    X-iDen-Ignore: HTTP/1.1\r\n
    Expect: 100-Continue\r\n
    [Header: Value]\r\n
    \r\n
    [Body]

Turns out that worked. The JVM was never updated or fixed, the hack shipped, and it worked consistently for the lifetime of those phones.

[1] https://en.wikipedia.org/wiki/IDEN

[2] "An origin server ... MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client" https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8....