This is a quick post to record how Chrome requests a WebM stream, how an HTTP server, such as Flumotion, responds to that request, and the stream format.
To begin with, when Chrome (I tested with version 10) 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 obviously will vary in each case. One thing to note is the Range header, a 0- means the server should return all data. If you sniff this message exchange using Wireshark, you will note 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
Usually the server also starts streaming the WebM data at this point. I say usually because at this point Chrome closes that TCP connection and makes the same request again. Why it does that is beyond me, but I’ll hazard a guess that it has to do with making sure that the server URL is correct and the server responds properly.
As a side note, I used the Node.js TCP proxy I posted about earlier, to sniff the messages above.