On Sunday, 07 December 2003 at 21:41, oddsock wrote:> At 01:19 PM 12/8/2003 +1100, you wrote: > >On Saturday 06 December 2003 17:12, Macsym wrote: > >> Hi Karl, > >> 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"); > > > >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 > >clients) > >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.Frankly I doubt that icecast will have much of an effect on the short-term development of Flash or IE. We're much more likely to just seem incompatible if we don't support the big-name clients. As long as the content-length header is only sent to clients in a blacklist, I think it's a good idea. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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 >clients) >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. oddsock <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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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 clients) in icecast2. Mike --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> 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.We still don't have a list of these "broken clients". If it's IE 4, then it's not ever going to be fixed and it should be worked around. If it's Mozilla CVS, then I agree. jack. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Monday 08 December 2003 14:41, oddsock wrote:> 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. >It's a choice between "don't work at all", and "work partially". Adding this feature (porting it from icecast 1.x) will have no effect on IE's existing or future behaviour. Remember: without this feature, these clients will not, now or in the forseeable future, work at all. Mike --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.