My guess is the reason browser don’t need HTTP response headers to process a response as a webpage is so they can support HTTP/0.9. These are simply “GET /resource.html” style requests and byte stream responses. No HTTP status codes or headers.

http://www.w3.org/Protocols/HTTP/AsImplemented.html

Why would a browser process a HTTP/0.9 style response when it made a HTTP/1.1 or HTTP/1.0 style request? The browser has no way of knowing what the server supports. For all it knows it really is talking to a HTTP/0.9 server which accepted the GET request line, ignored the HTTP request headers as invalid requests, and returned an HTTP/0.9 response. Backwards compatibility and all that jazz.

Is this all a guess? Yes. If I’m right is this stupid behavior for a modern browser? Indeed. The chance of finding a HTTP/0.9 server is far less than the chance of someone bouncing HTTP through some other text protocol.

re: HTTP/0.9, was there ever a specification? the first hit on google shows a BNF (sort of) that indicates a status line is required. this is just trivia, anyway.

yes, my ftp is no different from anyone else’s, but thankfully it runs on port 21

re: *.foo.com. you’re right. this means that google -can’t- have a publicly accessible ftp/smtp/whatevertp on a non-standard port anywhere on the web – how likely is that?

i think an interesting avenue to research would be to see if active script delivered during an SSL handshake could result in any exploitable scenarios. i think that area is just as likely to be vulnerable, but people don’t know how to easily intercept that SSL negotiation traffic