对IceCast的HTTP请求和响应

有一个对IceCast 2.3.2-kh29服务器MP3流HTTP://*：*/.MP3的HTTP请求和响应（一些数据被**隐藏）：

---

响应中未指定内容长度。尽管有要求，keep alive也不见了。这是正常情况吗？协议指定在这种情况下内容长度必须为。溪流开始播放。可能不是所有的头都以这种方式显示在LiveHTTPHeaders中？或者流是一种特殊情况，当使用某种人造内容长度时？

HTTP 1.0不要求指定内容长度。SHOUTcast/Icecast服务器不会指定内容长度，因为流是实时的，没有预先确定的长度。

和HTTP 1.1也可以在没有任何可能的播放续集的情况下工作？@Tramway11，正如我在您的其他问题中告诉您的，您听到的播放故障来自分块传输编码。严格来说，它们与内容长度标题无关。从技术上讲，HTTP/1.1传输需要内容长度或分块编码。这就是为什么使用HTTP/1.0通过HTTP进行流式传输。大多数客户端将能够处理不发送内容长度头的HTTP/1.1资源。我发现，通过在中断的HTTP/1.1流中指定

Connection:close

，可以最大限度地提高兼容性。不过最好使用HTTP/1.0。我看了今天晚上的节目，甚至在HTTP 1.0中没有分块编码。所以问题可能在另一个地方。在WireShark中，HTTP 1.0 200 OK在从GET开始的32秒后出现，然后播放停止。在这些数据到来之前。所以这出戏持续了32秒。@Tramway11，听起来好像出了什么问题。你能把这个包上传到什么地方吗？

    GET /*.mp3 HTTP/1.1
Host: ***:*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br: 192
ice-audio-info: bitrate=192;samplerate=44100;channels=2
icy-description: MP3 192 Kbps
icy-genre: *
icy-name: *
icy-pub: 1
icy-url: http://*
Server: Icecast 2.3.2-kh29
Cache-Control: no-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache