HTTP Status-Line (SL) Shenanigans

While working on HTTP-Basma, I had the idea of trying to construct "weird" (obfuscated looking) yet functional HTTP server response headers, that are still interpreted by the browser as valid server responses. I did that in an attempt to break the HTTP response headers parser of the library I used. And to my surprise, it is possible to come up with some very weird-looking functional responses that are correctly interpreted by the browser. For testing, I used Google Chrome (GC) and Microsoft Edge (ME); other browsers might work too.

I'll use the HTTP status code 302 for redirection as the signal to detect whether the browser is redirecting to the intended target/location server or not.

Let's take the following weird server responses:

Moon-Variant

&^*_hTtppotaetopotato|sdjhfsdhfkjsf*87627834 302

And,

Mars-Variant

&^
htTPzpdfbsnmf|sdjhfsdhfkjsf*87627834 302
Location: http://www.example.com

As shown, this HTTP status line is not what you'd expect to see from an HTTP server, requesting redirection to the domain "http://www.example.com". Nonetheless, the browsers in question interpret it correctly and redirect to the intended target.

Take this one too:

Jupiter-Variant

&^
htTPzpdfbsnmf|sdjhfsdhfkjsf*87627834 302sdkfj.gjvh 7236547hjgjsdgfjsdhgfjh
lOcATioN:http://www.example.com

And to make it weirder, take this one that encodes the redirect-to location IPv4 address in decimal 1572395042 (93.184.216.34). Additionally, it uses random custom headers just to make it harder to spot the important attributes in the response header section.

Earth-Variant

&^
htTPzpdfbsnmf|sdjhfsdhfkjsf*87627834 302sdkfj.gjvh 7236565465489745jgsdfjhgsdfjhdgsjfhgsdjghfdfgsjdhfs
df47hjgjsdgfjsdhgfjh
5465489745jgsdfjhgsdfjhdgsjfhgsdj:jhgsfjhsjhsdgf
KDNFNeC8LqyV0857jkhfkjsf:gsdfjhsfuys78657834
QfOuHdAnxW60uGCV7KsnGu5rIeXUQePE:jhgsfjhsjhsdgf
5465489745jgsdfjhgsdfjhdgsjfhgsdj:jhgsfjhsjhsdgf
JPyquhdzRS91P5Fem25E:HMK42O8iN0wmkRKDNFNeC8LqyV0qCfXU
lOcATioN:htTp:/\1572395042
HMK42O8iN0wmkRKDNFNeC8LqyV0qCfXU:KDNFNeC8Lqy
mcRUwcH:jhgsfjhsjhsdgf

And this one:

Venus-Variant

&^
htTpzpdfbsnmf|sdjhfsdhfkjsf*8762783bnzvxcznbx;cvzbxcvznxbcvzncv 302sdkfj.gjvh{ 7236547hjgjsdgfjsdhgfjh
xnvbxbcvnnc     vnxbvnx}
lOcATioN:htTp:/\1572395042

The reason why these weird responses work is because the browser parses the HTTP status line according to the following criterion:

The first 4 chars could be anything including (\r\n), followed by "HTTP" (case insensitive), any char other than SP (space) and line feed characters, SP, <status_code>

This is parsable using the following regex (nocase):

"^.{4}HTTP[^ \n] <status_code>[^ \n] <reason_phrase>\n"

If you backtrack and look into every example I provided you'll notice that all of them satisfy this criterion.

The browser might even rewrite the status line with an HTTP version. For example, some versions of Google Chrome would rewrite the Jupiter-Variant into this:

HTTP/1.0 302 sdkfj.gjvh 7236547hjgjsdgfjsdhgfjh
lOcATioN:http://www.example.com

Another tidbits of some versions of Google Chrome include:

1. If no status code is defined, then, GC rewrites the SL as HTTP/1.1 200 OK

2. If no SL is defined (the whole line), then, GC rewrites the SL as HTTP/0.9 200 OK

This was weird!

---

Mohamad Mokbel

June 30, 2026