Coyote Point load-balancer USER-AGENT bug

A truly wierd bug

[sitetruth]

We've discovered an amusing bug in Coyote Point Equalizer load balancers. This is truly wierd, but quite real. If an HTTP request going to one of these load balancers has a USER-AGENT string that ends in "m", but doesn't contain another "m", and the USER-AGENT string is the last element of the HTTP header, the load balancer silently drops the packet. You can try this on Coyote Point's own load balancers with these Telnet sessions:

This will just hang for a few seconds, or the server will close the connection without sending anything.
====
telnet www.coyotepoint.com 80
GET / HTTP/1.0
Host: www.example.com
User-agent: am

====

This works; the web page will be returned.
====
telnet www.coyotepoint.com 80
GET / HTTP/1.0
Host: www.example.com
User-agent: an

=====

Remember to send the blank line after the headers.

Note that the only difference is that the user agent changed from "am", which fails, to "an", which works. We have a Python program which tries many different user agent strings, and thus established the form of the failing pattern. It's really the load balancer doing this; in testing with a Coyote Point equipped site, the packets coming out of the load balancer have been monitored, and the ones with the final "m" just don't come out of the load balancer.

Coyote Point load balancers decode headers with regular expressions, and we suspect that somewhere in their code, there's a "\m" where a "\n" was intended.

Anyway, if you have Coyote Point gear, try the simple tests above, and see if it breaks.

This might explain some "why wasn't my site indexed by search engine ..." problems, although none of the big players have known user agent strings that meed these criteria. "exactseek.com" or "InternetSeer.com", maybe.

This has been reported to Coyote Point.