[icecast-dev] Missing headers in Icecast2

oddsock oddsock at oddsock.org
Sun Dec 7 19:41:37 PST 2003

At 01:19 PM 12/8/2003 +1100, you wrote:
>On Saturday 06 December 2003 17:12, Macsym wrote:
> > Hi Karl,
> >
> > I just checked in Icecast1 source, the line:
> >
> > if (client_wants_content_length (con))
> >           sock_write (con->sock, "Cache-Control: no-cache\r\nPragma:
> > no-cache\r\nConnection: close\r\nContent-Length: 54000000\r\n");
> >
> >
> > is located in "client.c". Shouldn't I add this line in "client.c" of
> > Icecast2 instead of "format_mp3.c" as you advised me? If so, what should I
> > add exactly and where in the code (of Icecast2's client.c)?
>After some discussion off-list with Jack:
>This is done for compatibility with broken clients (including IE, and
>presumably flash-in-IE). Upsides: it sort of works. Downsides: it has a fixed
>content-length, so the client will terminate after a finite period of time.
>It needs to be reasonably small, because the same broken clients pre-buffer a
>fixed percentage of the stream (so making it essentially infinite in length,
>such that the client never terminates, isn't an option).
>We should do this (based on User-Agent, once we have a list of fucked 
>in icecast2.

I strongly disagree...A solution that terminates a listener abruptly at a 
fixed content length seems like an incredibly bad solution.  Adding this 
kind of interoperability decreases the chances that broken clients will 
ever be fixed.


<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.

More information about the Icecast-dev mailing list