0

There's an HTTP request to the IceCast 2.3.2-kh29 server MP3 stream http://*:*/.mp3 and response (some data are **ed):

    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

The Content-Length is not specified in the response. Also keep-alive is missing, despite the request. Is it normal situation? The protocol specifies that Content-Length must be in this case. The stream starts playing. Can be somehow that not all headers are shown in LiveHTTPHeaders this way? Or the stream is a special case, when used some sort of artificial made Content-Length?

Tramway11
  • 419
  • 3
  • 9
  • 20

1 Answers1

1

HTTP 1.0 does not require that a content length is specified. SHOUTcast/Icecast servers will not specify the content length because the streams are live and there is no pre-determined length.

Brad
  • 159,648
  • 54
  • 349
  • 530
  • And HTTP 1.1 can work without it too without any possible playback sequels? – Tramway11 Jul 30 '13 at 18:04
  • @Tramway11, As I've told you in your other questions, the playback glitches you are hearing are from chunked transfer encoding. Strictly speaking, they have nothing to do with the content length header. Technically, HTTP/1.1 transfers require either a content length, or chunked encoding. That's why you use HTTP/1.0 for streaming over HTTP. Most clients will be able to cope with an HTTP/1.1 resource that does not send a content length header. I've found that you can maximize compatibility by specifying `Connection: close` in your broken HTTP/1.1 stream. Best to use HTTP/1.0 though. – Brad Jul 30 '13 at 18:17
  • I saw today's night, and the stop was even in HTTP 1.0 without chunked encoding. So the problem can be in other place. – Tramway11 Jul 30 '13 at 19:39
  • In WireShark it looks like HTTP 1.0 200 OK comes after 32 seconds from the GET and playing stops after this. Before this data comes. So the play lasts 32 seconds. – Tramway11 Jul 30 '13 at 21:22
  • @Tramway11, Sounds like something else is wrong then. Can you upload this packet capture somewhere? – Brad Jul 30 '13 at 21:33
  • I can send you by mail if you're OK with this. – Tramway11 Jul 30 '13 at 21:37
  • @Tramway11, I recommend posting a link to it on StackOverflow so everyone can learn. If you are looking for a consultant to help with your project, you can e-mail me at brad@audiopump.co. – Brad Jul 30 '13 at 21:39
  • http://rghost.ru/download/47785153/3dc99188e15ca837b0fc0744c64c6c343656efc0/packets310713.xml - some ip data are in * – Tramway11 Jul 30 '13 at 21:56
  • @Tramway11, This file doesn't contain the actual data. You need to post the entire capture file. I wouldn't worry about having your IP address visible. – Brad Jul 30 '13 at 22:56
  • Here it is: http://rghost.ru/download/47798282/54b07ca584f7963b6ff3465ad9c90b49b297d155/packets310713a.xml with some hosts replaced – Tramway11 Jul 31 '13 at 12:54
  • @Tramway11, This XML file is truncated, according to my copy of Wireshark. Don't post the XML, post a regular pcap file so that I can open it and help you. – Brad Jul 31 '13 at 13:15
  • http://rghost.ru/download/47799060/bf9708b112874b92eb4be14862413b7ed09e4188/packets310713c.pcap – Tramway11 Jul 31 '13 at 13:25
  • @Tramway11, Thanks for the packet capture. I've taken a look, and it's weird but it seems that Icecast is initiating the disconnection. The only reason I can think of that happening is if the source client is no longer sending data to the server. The server will disconnect clients if there is no additional data to send them. – Brad Aug 01 '13 at 00:37
  • Brad, thanks for the help. I tried on different clients in different cities and connections, but it happens. As I see, in this case the client only sends TCP acknowledgments, if receive is well. Besides this there's only one HTTP GET, yes? So I think there can be some error in the stream... but it's strange. Looks like data are not perceived as MP3. Why can different clients don't send data? – Tramway11 Aug 01 '13 at 12:50
  • @Tramway11, The client makes the request, and does not send data after that. This is perfectly normal. It should only be sending ACKs. Again, in this case the server disconnected the client, not the other way around. – Brad Aug 01 '13 at 13:16
  • Yes... but the reason is not unveiled. Do you know other ways to see the reason why it's disconnected? – Tramway11 Aug 01 '13 at 13:32
  • @Tramway11, Again, the only thing I can think of is that there is a problem with the source client. Try a different source for the stream and see if that helps. – Brad Aug 01 '13 at 14:22