This post shows how Chrome requests a WebM stream, how an HTTP server such as Flumotion responds to the request, and the stream format used.
When Chrome, version 10 at time of writing, encounters a video tag with a WebM source, it sends the following request
GET /webm-audio-video/ HTTP/1.1 Host: 192.168.2.2:9001 Connection: keep-alive Accept: */* User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.205 Safari/534.16 Accept-Encoding: gzip,deflate,sdch Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Range: bytes=0-<
The GET URI and Host header will depend on the request. Note the Range header, a
0- means the server should return all data. If you sniff this message exchange using Wireshark, you will see that this request goes to the HTTP host and port specified in the source URL. The server responds from a socket bound to any other randomly chosen port. That is how TCP works.
The response from a server to the above request may look like
HTTP/1.0 200 OK Date: Mon, 18 Apr 2011 18:37:20 GMT Connection: close Cache-control: private Content-type: video/webm Server: FlumotionHTTPServer/0.8.1
The server should start streaming WebM data at this point, but Chrome closes the TCP connection and makes the same request again, I am not sure why.
I used the Node.js TCP proxy to log the messages above.