--- Joshua Kinberg <jkinberg@...> wrote:



> what software are you referring to?

> Microsoft BITS is not an aggregator -- it is a technology that can be

> built into an aggregator though.



Actually, it's both a desert topping AND and floor wax.



If I remember correctly, I downloaded Microsoft's client at

http://tinyurl.com/assxy.



Cheers -



george





-------------------------------------

Eclectic Mix - http://EclecticMix.com

DRiP Investing - http://DRiPInvesting.org

Handmade Photographic Images - http://www.GLSmyth.com

Podcaster News - http://podcasternews.com/details.php?P=21











__________________________________

Yahoo! for Good - Make a difference this year.

http://brand.yahoo.com/cybergivingweek2005/

On 1/1/06, George L Smyth <glsmyth@...> wrote:

> --- Joshua Kinberg <jkinberg@...> wrote:

>

> > what software are you referring to?

> > Microsoft BITS is not an aggregator -- it is a technology that can be

> > built into an aggregator though.

>

> Actually, it's both a desert topping AND and floor wax.



And a completely undetectable poison!



(Oh, wait, that was a different sketch...)







--

Have Fun,

    Steve Eley (sfeley@...)

    ESCAPE POD - The Science Fiction Podcast Magazine

    http://www.escapepod.org

Look into a product called DrizzleCast - it's the only podcast aggregator I

know that uses BITS technology.







http://www.nuparadigm.com/Products/Toys/DrizzleCast/







GoFetch is a download product that uses it as well. It's also built into the

Windows Update system I think.







Hope that helps.







Patrick Melton







   _____



From: podcasters@yahoogroups.com [mailto:podcasters@yahoogroups.com] On

Behalf Of libsyn

Sent: Thursday, December 29, 2005 3:07 AM

To: podcasters@yahoogroups.com

Subject: [podcasters] Looking for information about user agent: Microsoft

BITS/6.6







Hey all-

We are seeing a HUGE amount of requests coming from a user agent identifying

itself as

"Microsoft BITS/6.6".  The problem is the ratio of total requests to unique

IP's is staggering.

Like worse than anything we've seen yet.  It appears to be hitting a few

popular video

podcasts we host.  Searching the web right now looking for more information

about what

agent/application or aggregator site this could be.  If anyone has any info,

please post.



Thanks all



love libsyn.















SPONSORED LINKS





Communication

<http://groups.yahoo.com/gads?t=ms&k=Communication+and+networking&w1=Communi

cation+and+networking&w2=Wireless+communication+and+networking&c=2&s=77&.sig

=ozdeqSR9iHuNl4GM8mtT5w>  and networking



Wireless

<http://groups.yahoo.com/gads?t=ms&k=Wireless+communication+and+networking&w

1=Communication+and+networking&w2=Wireless+communication+and+networking&c=2&

s=77&.sig=C2VMYm3EZ13VjeE5NNaKDg>  communication and networking







   _____



YAHOO! GROUPS LINKS







*  Visit your group "podcasters

<http://groups.yahoo.com/group/podcasters> " on the web.



*  To unsubscribe from this group, send an email to:

  podcasters-unsubscribe@yahoogroups.com

<mailto:podcasters-unsubscribe@yahoogroups.com?subject=Unsubscribe>



*  Your use of Yahoo! Groups is subject to the Yahoo!

<http://docs.yahoo.com/info/terms/>  Terms of Service.







   _____







[Non-text portions of this message have been removed]

Information about it can be found at

http://www.podcastingnews.com/archives/2005/03/drizzlecast_opt.html.  I am just

guessing that since it utilizes unused bandwidth, it is possible that it could

start and stop numerous times over the course of downloading a show, which

would explain the requests to IP Address question.  I'm trying it out now and

it appears to be working, but the problem (and it's a big one) is that the user

apparently has no choice over which shows of a podcast it takes.  I entered the

feed for Ultima Thule and it looks like it is setting up to download the past

50 shows, which is probably what is one the feed.  Not really a good idea, in

my mind.



Cheers -



george



--- libsyn <email@...> wrote:



> Hey all-

> We are seeing a HUGE amount of requests coming from a user agent identifying

> itself as

> "Microsoft BITS/6.6".  The problem is the ratio of total requests to unique

> IP's is staggering.

> Like worse than anything we've seen yet.  It appears to be hitting a few

> popular video

> podcasts we host.  Searching the web right now looking for more information

> about what

> agent/application or aggregator site this could be.  If anyone has any info,

> please post.

>

> Thanks all

>

> love libsyn.



-------------------------------------

Eclectic Mix - http://EclecticMix.com

DRiP Investing - http://DRiPInvesting.org

Handmade Photographic Images - http://www.GLSmyth.com

Podcaster News - http://podcasternews.com/details.php?P=21









__________________________________

Yahoo! for Good - Make a difference this year.

http://brand.yahoo.com/cybergivingweek2005/

Andre here, from TVTonic, the video aggregator featured in Windows Media

Center's

Online Spotlight.  The TVTonic client uses Microsoft BITS to download video

content.

Podcasters seeing traces of useragent Microsoft/BITS in their stats could

possibly be

seeing TVTonic users pulling their content, however they could also be coming

from other

RSS clients, such as the RSS reader built in to IE7 which uses BITS.



See http://blogs.msdn.com/rssteam/archive/2006/02/02/522642.aspx



BITS is the technology that Microsoft uses to deliver Windows Automatic Updates.

It is a

component designed to control and throttle background downloads as not to make

any

large resource hit on a user's computer.



But the problem, it seems, with BITS is that it makes a substantial number of

webserver

requests.  If you look at your server log you might think that BITS is hammering

your

bandwidth because of the high number of requests.  This is because it is making

requests

to the server for small chunks of a file rather than one request for the whole

file itself.

Once it has collected all of the bits of a file, it marks it as being finished

and makes the file

available to the user.



Right now Libsyn is blocking all requests from the Microsoft/BITS user agent.



See http://tinyurl.com/gh852



It seems that the bigger hosts are using custom load balancing and server

redirects that

mess up BITS.  Cachefly is failing to work with BITS all together though they

say they

support the range request and they claim their logs indicate the bytes are being

delivered.

We have contacted Libsyn, Cachefly, and Microsoft about these issues.



Obviously TVTonic would like to work with server admins to resolve the BITS

issues.

Please contact me off list by emailing asala [at] wavexpress [period] com if you

would like

to discuss.



Thanks,



Andre Sala

TVTonic Team



--- In podcasters@yahoogroups.com, "libsyn" <email@...> wrote:

>

> Hey all-

> We are seeing a HUGE amount of requests coming from a user agent identifying

itself as

> "Microsoft BITS/6.6".  The problem is the ratio of total requests to unique

IP's is

staggering.

> Like worse than anything we've seen yet.  It appears to be hitting a few

popular video

> podcasts we host.  Searching the web right now looking for more information

about

what

> agent/application or aggregator site this could be.  If anyone has any info,

please post.

>

> Thanks all

>

> love libsyn.

>

On 2 Mar 2006, at 23:35, André Sala wrote:

> But the problem, it seems, with BITS is that it makes a substantial

> number of webserver

> requests.  If you look at your server log you might think that BITS

> is hammering your

> bandwidth because of the high number of requests.  This is because

> it is making requests

> to the server for small chunks of a file rather than one request

> for the whole file itself.

> Once it has collected all of the bits of a file, it marks it as

> being finished and makes the file available to the user.



Presumably the requests show up in the logs with a 206 status code

and a response length that indicates that only a small fragment of

the the whole file has been returned?



> Right now Libsyn is blocking all requests from the Microsoft/BITS

> user agent.

>

> See http://tinyurl.com/gh852



  From Libsyn: "FYI: We have recently started rejecting requests from

the user-agent "Microsoft BITS" -- this is a poorly behaved library

from you know who that someone has been using, probably

unintentionally, to slam our servers. What this software does is make

a separate http request for every 1-k chunk of a file, which ends up

slamming our servers and bloating your stats. This has primarily

affected people publishing video files."



That seems a little disingenuous from libsyn to me. Partial content

requests are a legal part of the HTTP protocol. If libsyn's servers

and stats analysis get upset by them then that implies that it's

libsyn that have the problem.



Have you guys at TVTronic analysed what's happening at the HTTP

level? I assume BITS is making legal well formed partial content

requests?



--

Andy Armstrong, hexten.net

Yes, BITS is making legal, well-formed partial content requests:



GET /media/tiki/TikiBarTV_13.mov HTTP/1.1

Accept: */*

Accept-Encoding: identity

Range: bytes=0-264601

User-Agent: Microsoft BITS/6.6

Host: media.libsyn.com

Connection: Keep-Alive



Apparently, Libsyn's big concern with BITS is how it deals with redirects.

Before they blocked Microsoft/BITS requests, our client was downloading

their files fine.  However, the stats were being inflated because BITS was

getting re-directed every time it was sending a new range request.  This is

arguably inefficient, but it is not clear how we can keep BITS from making

that redirect for every packet.



We would like very much to resolve this issue so that our users can

subscribe to libsyn's users' content.



On 3/3/06, Andy Armstrong <andy@...> wrote:

>

> Presumably the requests show up in the logs with a 206 status code

> and a response length that indicates that only a small fragment of

> the the whole file has been returned?

>

>

> > Right now Libsyn is blocking all requests from the Microsoft/BITS

> > user agent.

> >

> > See http://tinyurl.com/gh852

>

>  From Libsyn: "FYI: We have recently started rejecting requests from

> the user-agent "Microsoft BITS" -- this is a poorly behaved library

> from you know who that someone has been using, probably

> unintentionally, to slam our servers. What this software does is make

> a separate http request for every 1-k chunk of a file, which ends up

> slamming our servers and bloating your stats. This has primarily

> affected people publishing video files."

>

> That seems a little disingenuous from libsyn to me. Partial content

> requests are a legal part of the HTTP protocol. If libsyn's servers

> and stats analysis get upset by them then that implies that it's

> libsyn that have the problem.

>

> Have you guys at TVTronic analysed what's happening at the HTTP

> level? I assume BITS is making legal well formed partial content

> requests?

>

> --

> Andy Armstrong, hexten.net

>

>





[Non-text portions of this message have been removed]

On 3/3/06, André Sala <andrensala@...> wrote:

>

>  Yes, BITS is making legal, well-formed partial content requests:

>

> GET /media/tiki/TikiBarTV_13.mov HTTP/1.1

> Accept: */*

> Accept-Encoding: identity

> Range: bytes=0-264601

> User-Agent: Microsoft BITS/6.6

> Host: media.libsyn.com

> Connection: Keep-Alive

>

> Apparently, Libsyn's big concern with BITS is how it deals with redirects.

> Before they blocked Microsoft/BITS requests, our client was downloading

> their files fine.  However, the stats were being inflated because BITS was

> getting re-directed every time it was sending a new range request.  This

> is

> arguably inefficient, but it is not clear how we can keep BITS from making

> that redirect for every packet.

>

> We would like very much to resolve this issue so that our users can

> subscribe to libsyn's users' content.

>

>

Well...I am sure, knowing Libsyn's reputation with podcasters, they are

working on a solution.



This happens when people suddenly drops a big stone into a tranquil

pond...the ripples start but will eventually dissipate.



My minute of Zen for you all!



;-)





--



Andy Bilodeau

PodCaster



The AndyCast PodCast

You'll laugh 'til you stop!

http://www.andycast.net





[Non-text portions of this message have been removed]

On 3 Mar 2006, at 18:17, Andy Bilodeau wrote:

> Well...I am sure, knowing Libsyn's reputation with podcasters, they

> are

> working on a solution.



And in the mean time instead of acknowledging that this is their

problem they're trying to deflect blame onto BITS...



--

Andy Armstrong, hexten.net

On the libsyn support blog:



http://support.libsyn.com/index.php?post_id=64313



They are calling the range requests from BITS "unfriendly," "wacky," and

"destructive."



If anyone has an account with Libsyn and does not want their content

censored in Internet Explorer 7, Windows Vista, or Windows Media Center (via

TVTonic), please email Libsyn and ask that they stop blocking BITS requests.





[Non-text portions of this message have been removed]

--- André Sala <andrensala@...> wrote:

> If anyone has an account with Libsyn and does not

> want their content

> censored in Internet Explorer 7, Windows Vista, or

> Windows Media Center (via

> TVTonic), please email Libsyn and ask that they stop

> blocking BITS requests.



First of all, nobody is censoring anything. Libsyn

made a business decision based on a new phenomenon

that was occuring that was messing up with their

numbers.



I'm gonna go out on a limb here and say that most

people had no idea what BITS was until people started

to complain about bogus numbers. Not just on Libsyn,

but also on individual podcasters sites.



I think what needs to happen is a dialogue between

those who use BITS technology, and the podcasting

community. People can go back and forth all they want.

Wacky this, censor that. Both sides sound very

unproffesional to me.



What has the conversation been between Libsyn and the

software makers that use BITS tech? I would like to

know how this new type of tech can help us instead of

screwing around with our numbers? How can we properly

prepare our sites to accept these requests while

getting 'accurate' numbers?



If there is a fix, then let's hear about it.

Otherwise, this sandbox brawl will continue until the

lunch bell rings;)



Again, I am only going by what I have seen so far, not

knowing anything about BITS tech. It sounds like it

has great potential. I will look into it more myself,

and see its benefits.







Paul Puri



The Podcast Guild Planning Commitee.

http://podcastguild.com/



Podsafe Gear...Gear for Podcasters

http://podsafegear.com



Unsigned Podcast Network

Skype:unsignedpodcast

unsignedpodcast@...



The site: http://www.unsignedpodcastnetwork.com/

The blog: http://unsignedpodcast.blogspot.com/

The feed: http://feeds.feedburner.com/unsignedpodcast/dmMp

The store: http://www.cafepress.com/unsignedpodcast





Promotion without shame.

Podcasting Announcements

http://groups.yahoo.com/group/podcastingannouncements/



The Official Podcasters Wiki: http://podcasterswiki.com

On 4 Mar 2006, at 01:38, Paul Puri wrote:

> First of all, nobody is censoring anything. Libsyn

> made a business decision based on a new phenomenon

> that was occuring that was messing up with their

> numbers.



The problem is that they're blaming BITS when the fault is with

Libsyn's infrastructure.



> I'm gonna go out on a limb here and say that most

> people had no idea what BITS was until people started

> to complain about bogus numbers. Not just on Libsyn,

> but also on individual podcasters sites.



Yes, but the potential for HTTP subrange requests has been around for

years and anybody who sells a web hosting service needs to be able to

handle those requests otherwise their service is broken. It really is

as simple as that.



Now it's quite understandable that Libsyn would have a problem with

these requests when they first started to see them - but the

appropriate response is "Oops, we didn't anticipate this - sorry

folks - we're working on a fix".



> I think what needs to happen is a dialogue between

> those who use BITS technology, and the podcasting

> community. People can go back and forth all they want.

> Wacky this, censor that. Both sides sound very

> unproffesional to me.



To be clear it's not just BITS. BITS is a Microsoft technology that's

built on an a long standing feature of the HTTP protocol -

specifically the ability to request a file in chunks rather than all

at once. It makes a lot of sense to use HTTP subrange requests when

you're dealing with large transfers: it makes the transfers

restartable and allows better control over how long resources are

tied up by the transfer.



> What has the conversation been between Libsyn and the

> software makers that use BITS tech? I would like to

> know how this new type of tech can help us instead of

> screwing around with our numbers? How can we properly

> prepare our sites to accept these requests while

> getting 'accurate' numbers?



If you host your files on a vanilla Apache webserver there's

absolutely no preparation to be done. Something about Libsyn's setup

is causing the problem but instead of acknowledging that they're

attempting to pass the blame to the authors of user agents.



You may find that requests for partial content mess with your stats -

which is one of the reasons I wrote Podalyzer - it recognises

multiple 206 (partial content) response codes and counts them properly.



> If there is a fix, then let's hear about it.

> Otherwise, this sandbox brawl will continue until the

> lunch bell rings;)



If it's a brawl it's a brawl between Libsyn and the HTTP protocol. It

would be absolutely wrong for anyone to change their code not to use

HTTP partial requests in response to this. Partial requests are

absolutely legal in the HTTP protocol and they are potentially

beneficial both to users (restartable downloads, fine grained control

on bandwidth usage) and hosting companies (resources on the server

tied up for a shorter period).



> Again, I am only going by what I have seen so far, not

> knowing anything about BITS tech. It sounds like it

> has great potential. I will look into it more myself,

> and see its benefits.



Please don't start giving MS the credit for a feature of the HTTP

protocol :)



--

Andy Armstrong, hexten.net

--- Andy Armstrong <andy@...> wrote:

> Yes, but the potential for HTTP subrange requests

> has been around for

> years and anybody who sells a web hosting service

> needs to be able to

> handle those requests otherwise their service is

> broken. It really is

> as simple as that.



If it has been around awhile, and forgive me for my

ignorance, why is there any problems at all? Is it the

BITS implementation itself? If this protocol has been

around since 99, then why are we just now hearing of

these issues? Again, not as smart as you are(being

sincere here), but I am sure that this problem would

have been around longer. I know podcasting has not

been around that long, but these issues have not been

around for more than a few months. So, I'm confused.



> Now it's quite understandable that Libsyn would have

> a problem with

> these requests when they first started to see them -

> but the

> appropriate response is "Oops, we didn't anticipate

> this - sorry

> folks - we're working on a fix".



I agree. Libsyn probably got caught off gaurd by this.

And their response was rather childish, but somebody

accusing them of censorship is just a bunch of

cacadoodypoopoo. Both sides are not playing with a

full deck as to that respect.



> You may find that requests for partial content mess

> with your stats -

> which is one of the reasons I wrote Podalyzer - it

> recognises

> multiple 206 (partial content) response codes and

> counts them properly.



I'm confused again. If this tech has been around since

99, why would I need to use a third party software?

Shouldn't it be routine? If this protocol is as old as

it is supposed to be, then there should not be any

issues.



> If it's a brawl it's a brawl between Libsyn and the

> HTTP protocol. It

> would be absolutely wrong for anyone to change their

> code not to use

> HTTP partial requests in response to this. Partial

> requests are

> absolutely legal in the HTTP protocol and they are

> potentially

> beneficial both to users (restartable downloads,

> fine grained control

> on bandwidth usage) and hosting companies (resources

> on the server

> tied up for a shorter period).



Again, the issue must be something new. Because it has

just started up recently. Libsyn has been here since a

better part of last year. Why have they just been

experiencing these problems recently?



Confused and still awake at 4am,







Paul Puri



The Podcast Guild Planning Commitee.

http://podcastguild.com/



Podsafe Gear...Gear for Podcasters

http://podsafegear.com



Unsigned Podcast Network

Skype:unsignedpodcast

unsignedpodcast@...



The site: http://www.unsignedpodcastnetwork.com/

The blog: http://unsignedpodcast.blogspot.com/

The feed: http://feeds.feedburner.com/unsignedpodcast/dmMp

The store: http://www.cafepress.com/unsignedpodcast





Promotion without shame.

Podcasting Announcements

http://groups.yahoo.com/group/podcastingannouncements/



The Official Podcasters Wiki: http://podcasterswiki.com

On 4 Mar 2006, at 11:54, Paul Puri wrote:

> If it has been around awhile, and forgive me for my

> ignorance, why is there any problems at all? Is it the

> BITS implementation itself? If this protocol has been

> around since 99, then why are we just now hearing of

> these issues? Again, not as smart as you are(being

> sincere here), but I am sure that this problem would

> have been around longer. I know podcasting has not

> been around that long, but these issues have not been

> around for more than a few months. So, I'm confused.



Because it's chiefly a benefit for large transfers (and secondarily

restartable transfers) it's not something people have used a great

deal. It's also not a problem because normally configured web servers

handle partial content requests perfectly well out of the box. Off

the top of my head Adobe Acrobat and wget (unix command line tool)

both use HTTP 1.1 partial transfers and have been working fine for

years.



It seems that libsyn have set their hosting up in such a way that it

doesn't handle requests for partial content gracefully. That wasn't a

problem until somebody decided that it would be a good idea for a

podcatcher to use partial content requests. Libsyn are a web hosting

company; they serve all their content using the HTTP 1.1 protocol. As

such its their responsibility to handle legal HTTP 1.1 requests even

if those requests are using aspects of the protocol that they didn't

anticipate being used - that's one of the basic technical

undertakings a web hosting company makes to its customers.



While it's quite understandable that they'd have a problem that has

only been exposed now they've started receiving a large number of

partial content requests the correct response is "we're sorry, we'll

fix it" not "we've banned these misbehaved clients".



And just to be clear - this is a libsyn problem - other hosting

companies who are using Apache, IIS or some other webserver without

having customised their setup in the way Libsyn apparently have will

have -no problems whatsoever- with these requests.



> I agree. Libsyn probably got caught off gaurd by this.

> And their response was rather childish, but somebody

> accusing them of censorship is just a bunch of

> cacadoodypoopoo. Both sides are not playing with a

> full deck as to that respect.



Yes, censorship was an unnecessarily emotive word. But I can

certainly understand Andre's anger and frustration at libsyn's response.



>> You may find that requests for partial content mess

>> with your stats -

>> which is one of the reasons I wrote Podalyzer - it

>> recognises

>> multiple 206 (partial content) response codes and

>> counts them properly.

>

> I'm confused again. If this tech has been around since

> 99, why would I need to use a third party software?

> Shouldn't it be routine? If this protocol is as old as

> it is supposed to be, then there should not be any

> issues.



Core software - like webservers - have to be written to the letter of

the HTTP spec because when they say 'I speak HTTP' they effectively

enter into a contract (in the software sense) that they will

correctly handle valid HTTP requests.



Log analysis on other hand is not such a well defined business (who

said 'black art'?) - log analysis is about looking at the log files

you have and applying heuristics to those to try and infer from them

what happened - in terms of number of downloads, unique visitors,

dwell time etc etc. In spite of what anyone says to the contrary

these figures are /always/ estimates.



So log analysis tools have to evolve as the traffic they analyse

changes and it's entirely proper that they should do so - but web

servers have to comply with HTTP 1.1 otherwise they're broken.



And of course if you keep your raw log files you can always go back

and analyse them again with an improved analysis tool.



>

>> If it's a brawl it's a brawl between Libsyn and the

>> HTTP protocol. It

>> would be absolutely wrong for anyone to change their

>> code not to use

>> HTTP partial requests in response to this. Partial

>> requests are

>> absolutely legal in the HTTP protocol and they are

>> potentially

>> beneficial both to users (restartable downloads,

>> fine grained control

>> on bandwidth usage) and hosting companies (resources

>> on the server

>> tied up for a shorter period).

>

> Again, the issue must be something new. Because it has

> just started up recently. Libsyn has been here since a

> better part of last year. Why have they just been

> experiencing these problems recently?



Imagine: you buy a computer with a firewire interface but you don't

try to use the interface for six months; when you do you find out

that the interface is dead. Presumably there was a manufacturing

defect but you don't find out until you try to use it. Similarly (in

the absence from a better explanation from libsyn) what we're seeing

here is libsyn delivering a product with a defect that wasn't exposed

because nobody attempted to exercise the broken functionality until

now. That doesn't make it any less broken though.



When you set up a web hosting company you don't have to test your

service against every possible valid HTTP 1.1 request - instead you

use server software such as Apache that /has/ been tested against

billions of HTTP 1.1 requests and rely on it to do the right thing.

It may be sitting there just waiting to handle a request of a type

it's never seen before - and you don't have to worry about that

because you know Apache will do the right thing.



But if you make changes to your configuration in a way that might

impact on your ability to handle correctly formed HTTP 1.1 request /

you/ take on responsibility for testing those changes even if they

concern requests of a type you have never previously seen.



A web hosting service is not "we handle all the types of requests

we've thought of" it's "we handle all valid HTTP 1.1 requests, even

the ones we haven't thought of".



That may sound like a big ask. It is. But that's what you undertake

to do when you set up a web hosting company.





--

Andy Armstrong, hexten.net

--- Andy Armstrong <andy@...> wrote:

> Because it's chiefly a benefit for large transfers

> (and secondarily

> restartable transfers) it's not something people

> have used a great

> deal. It's also not a problem because normally

> configured web servers

> handle partial content requests perfectly well out

> of the box. Off

> the top of my head Adobe Acrobat and wget (unix

> command line tool)

> both use HTTP 1.1 partial transfers and have been

> working fine for

> years.



Thanks for your precise and ez to understand response

Andy. I actually get it now. Hopefully Libsyn will

have this fixed soon, and all can be happy in

podcasting land once again.



Gotta get a couple of hours of sleep now.

Hmmmm....4:45AM, gotta wake up at 7:00AM. Sleeping

almost seems like a waste of time;)







Paul Puri



The Podcast Guild Planning Commitee.

http://podcastguild.com/



Podsafe Gear...Gear for Podcasters

http://podsafegear.com



Unsigned Podcast Network

Skype:unsignedpodcast

unsignedpodcast@...



The site: http://www.unsignedpodcastnetwork.com/

The blog: http://unsignedpodcast.blogspot.com/

The feed: http://feeds.feedburner.com/unsignedpodcast/dmMp

The store: http://www.cafepress.com/unsignedpodcast





Promotion without shame.

Podcasting Announcements

http://groups.yahoo.com/group/podcastingannouncements/



The Official Podcasters Wiki: http://podcasterswiki.com

On 4 Mar 2006, at 12:38, Andy Armstrong wrote:

> Imagine: you buy a computer with a firewire interface but you don't

> try to use the interface for six months; when you do you find out

> that the interface is dead. Presumably there was a manufacturing

> defect but you don't find out until you try to use it. Similarly (in

> the absence from a better explanation from libsyn) what we're seeing

> here is libsyn delivering a product with a defect that wasn't exposed

> because nobody attempted to exercise the broken functionality until

> now. That doesn't make it any less broken though.



Or for an example closer to this list's collective experiences:



You buy a car that has an interface for an MP3 player - but you don't

yet have an MP3 player. In six months you buy an MP3 player of the

appropriate type but find that it doesn't work. You try a friend's

player of the same type that works with their car and find that that

too doesn't work with your car. Who's to blame?



--

Andy Armstrong, hexten.net

I do believe MS is moving more and more toward the BITS protocol in its

newest offerings.  It helps extend the life of legacy networks by adapting

to network conditions and slowing down or speeding up as appropriate.  As

such, the recent public beta of ie7 may be the source of some of the

increase in requests.



On 3/4/06, Paul Puri <prp6040@...> wrote:

>

> --- Andy Armstrong <andy@...> wrote:

>

> If it has been around awhile, and forgive me for my

> ignorance, why is there any problems at all? Is it the

> BITS implementation itself? If this protocol has been

> around since 99, then why are we just now hearing of

> these issues?





[Non-text portions of this message have been removed]

Andre,



I am a Libsyn customer, and quite frankly, I agree with them and take

umbrage at your classifying their decision to block BITS as censoring.

  BITS is a poorly behaved protocol that makes sense if you're

Microsoft and hosting your files at MS.  But compared to how most file

download protocols, it is badly thought out and while it may comply

with the letter of download protocols, it obviously does not play well

with others.



If you want to keep this conversation going and can keep it factual,

that's fine.  But throwing in emotionally charged words like

'censored' does you no credit and hurts your argument more than it

helps.  I'm sorry Libsyn's choice affects how your company is

designing its software, but as a person who uses Libsyn, I'm going to

back them on this argument, both with words and money.



Martin



On 3/3/06, André Sala <andrensala@...> wrote:

> On the libsyn support blog:

>

> http://support.libsyn.com/index.php?post_id=64313

>

> They are calling the range requests from BITS "unfriendly," "wacky," and

> "destructive."

>

> If anyone has an account with Libsyn and does not want their content

> censored in Internet Explorer 7, Windows Vista, or Windows Media Center (via

> TVTonic), please email Libsyn and ask that they stop blocking BITS requests.

>

>

> [Non-text portions of this message have been removed]

>

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

>

>





--

Martin McKeay, CISSP, CCNA

The Network Security Podcast

http://www.mckeay.net/

http://podcastroundtable.com/

http://www.computerworld.com/blogs/mckeay

YIM:  mmckeay@...

916-231-9479

On 3/3/06, Martin McKeay <Martin@...> wrote:

>

> If you want to keep this conversation going and can keep it factual,

> that's fine.  But throwing in emotionally charged words like

> 'censored' does you no credit and hurts your argument more than it

> helps.  I'm sorry Libsyn's choice affects how your company is

> designing its software, but as a person who uses Libsyn, I'm going to

> back them on this argument, both with words and money.



If all the facts in this thread are correct (and I haven't verified

them myself), Libsyn's made a choice that will potentially prevent

millions of Windows Media Player users from downloading your files.

These aren't people with any stake in this technical argument --

they're just folks who happen to use a convenient program that's

already on their computer, who might like your podcast, but who will

never hear it.



You're cool with that?





--

Have Fun,

    Steve Eley (sfeley@...)

    ESCAPE POD - The Science Fiction Podcast Magazine

    http://www.escapepod.org

I have more problems with Microsoft's history of creating new

protocols and standards than I do with any one hosting service

protecting themselves in a temporary manner.  Libsyn hasn't said

they'll never allow BITS to work, just that it is causing a problem in

the current implementation.



Martin



On 3/3/06, Stephen Eley <SFEley@...> wrote:

> On 3/3/06, Martin McKeay <Martin@...> wrote:

> >

> > If you want to keep this conversation going and can keep it factual,

> > that's fine.  But throwing in emotionally charged words like

> > 'censored' does you no credit and hurts your argument more than it

> > helps.  I'm sorry Libsyn's choice affects how your company is

> > designing its software, but as a person who uses Libsyn, I'm going to

> > back them on this argument, both with words and money.

>

> If all the facts in this thread are correct (and I haven't verified

> them myself), Libsyn's made a choice that will potentially prevent

> millions of Windows Media Player users from downloading your files.

> These aren't people with any stake in this technical argument --

> they're just folks who happen to use a convenient program that's

> already on their computer, who might like your podcast, but who will

> never hear it.

>

> You're cool with that?

>

>

> --

> Have Fun,

>    Steve Eley (sfeley@...)

>    ESCAPE POD - The Science Fiction Podcast Magazine

>    http://www.escapepod.org

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

>

>





--

Martin McKeay, CISSP, CCNA

The Network Security Podcast

http://www.mckeay.net/

http://podcastroundtable.com/

http://www.computerworld.com/blogs/mckeay

YIM:  mmckeay@...

916-231-9479

On 4 Mar 2006, at 02:37, Martin McKeay wrote:

> I have more problems with Microsoft's history of creating new

> protocols and standards than I do with any one hosting service

> protecting themselves in a temporary manner.  Libsyn hasn't said

> they'll never allow BITS to work, just that it is causing a problem in

> the current implementation.



It's not a new Microsoft protocol - partial requests are part of the

HTTP 1.1 spec dated June 1999.



  From ftp://ftp.isi.edu/in-notes/rfc2616.txt (the HTTP 1.1 spec)



     The semantics of the GET method change to a "partial GET" if the

     request message includes a Range header field. A partial GET

requests

     that only part of the entity be transferred, as described in section

     14.35. The partial GET method is intended to reduce unnecessary

     network usage by allowing partially-retrieved entities to be

     completed without transferring data already held by the client.



So please don't credit Microsoft with inventing something new here.



--

Andy Armstrong, hexten.net

On 4 Mar 2006, at 01:45, Martin McKeay wrote:

> I am a Libsyn customer, and quite frankly, I agree with them and take

> umbrage at your classifying their decision to block BITS as censoring.

>  BITS is a poorly behaved protocol that makes sense if you're

> Microsoft and hosting your files at MS.  But compared to how most file

> download protocols, it is badly thought out and while it may comply

> with the letter of download protocols, it obviously does not play well

> with others.



Explain please. In what way is BITS 'poorly behaved'?



--

Andy Armstrong, hexten.net

On 4 Mar 2006, at 01:21, André Sala wrote:

> They are calling the range requests from BITS "unfriendly,"

> "wacky," and

> "destructive."

>

> If anyone has an account with Libsyn and does not want their content

> censored in Internet Explorer 7, Windows Vista, or Windows Media

> Center (via

> TVTonic), please email Libsyn and ask that they stop blocking BITS

> requests.



Does anyone have contact details for someone sensible at libsyn that

they could mail me off list?



--

Andy Armstrong, hexten.net

I would like to retract my use of the word "censored" in this post.  It was

the wrong word choice, fueled by my frustration with the situation.  I

should have used the word "blocked."  Libsyn is not censoring anyone.  They

are a great service for this community, and I'm sure we'll have a solution

for this issue very soon.  My apologies to Libsyn.



On 3/3/06, André Sala <andrensala@...> wrote:

>

> If anyone has an account with Libsyn and does not want their content

> censored in Internet Explorer 7, Windows Vista, or Windows Media Center (via

> TVTonic), please email Libsyn and ask that they stop blocking BITS requests.

>





[Non-text portions of this message have been removed]

--- Andr� Sala <andrensala@...> wrote:

> I would like to retract my use of the word

> "censored" in this post.  It was

> the wrong word choice, fueled by my frustration with

> the situation.  I

> should have used the word "blocked."  Libsyn is not

> censoring anyone.  They

> are a great service for this community, and I'm sure

> we'll have a solution

> for this issue very soon.  My apologies to Libsyn.



Now that I understand what is going on myself, I

understand all the frustration on both sides. I'm not

sure what Libsyn is doing about this situation. Andre,

do you know if anyone on your end has talked to them

in an attempt to help them out?



I was thinking of changing to Libsyn after this month,

but this seems like a decent sized hiccup. Once this

issue gets resolved, they are getting my hard earned

cash.







Paul Puri



The Podcast Guild Planning Commitee.

http://podcastguild.com/



Podsafe Gear...Gear for Podcasters

http://podsafegear.com



Unsigned Podcast Network

The site: http://www.unsignedpodcastnetwork.com/

The feed: http://feeds.feedburner.com/unsignedpodcast/dmMp

Skype:unsignedpodcast

unsignedpodcast@...





The Official Podcasters Wiki: http://podcasterswiki.com



Promotion without shame.

Podcasting Announcements

http://groups.yahoo.com/group/podcastingannouncements/

Thank you Andre, and I bow to your superiour understanding of the

protocols involved.  I'm a security geek and auditor, I make no

pretension of knowing the ins and outs of every protocol.  But I do

know Microsoft and their tendency to do things their own way, even

though that might not be the case in this instance.



Hopefully Libsyn will sort this all out shortly.



Martin



On 3/4/06, André Sala <andrensala@...> wrote:

> I would like to retract my use of the word "censored" in this post.  It was

> the wrong word choice, fueled by my frustration with the situation.  I

> should have used the word "blocked."  Libsyn is not censoring anyone.  They

> are a great service for this community, and I'm sure we'll have a solution

> for this issue very soon.  My apologies to Libsyn.







--

Martin McKeay, CISSP, CCNA

The Network Security Podcast

http://www.mckeay.net/

http://podcastroundtable.com/

http://www.computerworld.com/blogs/mckeay

YIM:  mmckeay@...

916-231-9479

Hey Guys,

Just catching up on the thread.  I believe Blunt over here is talking

with Andre right now to come up with a resolution.  We want what's

best for the podcasters, so we will get fixes in for this and make

sure that we have functionality for IE and Vista.  We are not always

sure what is friendly/unfriendly as far as all the variations of

traffic that we get, it can be confusing at times.  In the end we are

just trying to build the best system we can.  Any Microsoft eyes out

there?  We'd love to have your shop talk ear for a minute.

Thanks all,



Dave Mansueto



On Mar 4, 2006, at 1:38 PM, Martin McKeay wrote:



> Thank you Andre, and I bow to your superiour understanding of the

> protocols involved.  I'm a security geek and auditor, I make no

> pretension of knowing the ins and outs of every protocol.  But I do

> know Microsoft and their tendency to do things their own way, even

> though that might not be the case in this instance.

>

> Hopefully Libsyn will sort this all out shortly.

>

> Martin

>

> On 3/4/06, André Sala <andrensala@...> wrote:

>> I would like to retract my use of the word "censored" in this

>> post.  It was

>> the wrong word choice, fueled by my frustration with the

>> situation.  I

>> should have used the word "blocked."  Libsyn is not censoring

>> anyone.  They

>> are a great service for this community, and I'm sure we'll have a

>> solution

>> for this issue very soon.  My apologies to Libsyn.

>

>

>

> --

> Martin McKeay, CISSP, CCNA

> The Network Security Podcast

> http://www.mckeay.net/

> http://podcastroundtable.com/

> http://www.computerworld.com/blogs/mckeay

> YIM:  mmckeay@...

> 916-231-9479

>

>

>

> Yahoo! Groups Links

>

>

>

>

>

>

On 4 Mar 2006, at 22:55, Liberated Syndication Support wrote:

> Hey Guys,

> Just catching up on the thread.  I believe Blunt over here is talking

> with Andre right now to come up with a resolution.  We want what's

> best for the podcasters, so we will get fixes in for this and make

> sure that we have functionality for IE and Vista.  We are not always

> sure what is friendly/unfriendly as far as all the variations of

> traffic that we get, it can be confusing at times.  In the end we are

> just trying to build the best system we can.  Any Microsoft eyes out

> there?  We'd love to have your shop talk ear for a minute.



I'll keep this brief - I'm already in trouble for my vaguely

obsessive response to this issue :)



1) You know that this isn't a Microsoft specific issue, right? I'm

seeing a lot of 206 response

     codes for PSPRssChannel-agent/1.0.0 libhttp/1.0.0 too.



2) So we can keep some of the more impenetrable geekery off this list

I've started a mailing list

     for hardcore podcasting tech:

        http://podfamily.net/mailman/listinfo/podcast-tech



     It's a place where we can talk about servers, clients, protocols,

XML, RSS in a robust way

     without polluting this list.



--

Andy Armstrong, hexten.net

On 3 Mar 2006, at 17:02, André Sala wrote:

> We would like very much to resolve this issue so that our users can

> subscribe to libsyn's users' content.



As I said on the Libsyn forum I'm a little disappointed that they're

trying to pin the blame on a client that is issuing perfectly legal,

well formed requests. In the absence of any response to the contrary

from them we're left to conclude that they're trying to deflect blame

onto you so that instead of their users pressuring them for a

solution those users will take away the message that they've had to

block access to a rogue podcatcher and that to do so was merely due

diligence on their part.



We really could do with hearing something from Libsyn about now...



And just for the record I have no affiliation with Andre's company

and am not at all accustomed to defending Microsoft. I believe Sony

have a client that makes similar partial requests and presumably

causes similar problems for Libsyn - so I'm in the amusing position

of defending the two companies who are right at the top of my shit

list at the moment :)



--

Andy Armstrong, hexten.net

The bigger issue with blocking BITS is that Microsoft has announced that the

entire "Windows RSS Platform" will use BITS to download enclosures.



See  http://blogs.msdn.com/rssteam/archive/2006/02/02/522642.aspx



Any podcast hosting service blocking BITS is probably going to see a

backlash from their users when those podcasters realize that the built-in

RSS functionality in Vista (and IE7 for XP) mysteriously will not download

their content.



On 3/3/06, Andy Armstrong <andy@...> wrote:

>

>  On 3 Mar 2006, at 17:02, André Sala wrote:

> > We would like very much to resolve this issue so that our users can

> > subscribe to libsyn's users' content.

>

> As I said on the Libsyn forum I'm a little disappointed that they're

> trying to pin the blame on a client that is issuing perfectly legal,

> well formed requests. In the absence of any response to the contrary

> from them we're left to conclude that they're trying to deflect blame

> onto you so that instead of their users pressuring them for a

> solution those users will take away the message that they've had to

> block access to a rogue podcatcher and that to do so was merely due

> diligence on their part.

>

> We really could do with hearing something from Libsyn about now...

>

> And just for the record I have no affiliation with Andre's company

> and am not at all accustomed to defending Microsoft. I believe Sony

> have a client that makes similar partial requests and presumably

> causes similar problems for Libsyn - so I'm in the amusing position

> of defending the two companies who are right at the top of my shit

> list at the moment :)

>

> --

> Andy Armstrong, hexten.net

>

>

>

>  SPONSORED LINKS

>   Communication and

networking<http://groups.yahoo.com/gads?t=ms&k=Communication+and+networking&w1=C\

ommunication+and+networking&w2=Computer+security&w3=Computer+training&c=3&s=80&.\

sig=A8JypvKmrStpN6fDh9U3Og>  Computer

>

security<http://groups.yahoo.com/gads?t=ms&k=Computer+security&w1=Communication+\

and+networking&w2=Computer+security&w3=Computer+training&c=3&s=80&.sig=1rOpipQ2G\

5JuUh4FQdtUjw>  Computer

>

training<http://groups.yahoo.com/gads?t=ms&k=Computer+training&w1=Communication+\

and+networking&w2=Computer+security&w3=Computer+training&c=3&s=80&.sig=DoYkI4Rqe\

_5Hu64wdfCpSQ>

>  ------------------------------

> YAHOO! GROUPS LINKS

>

>

>    -  Visit your group "podcasters<http://groups.yahoo.com/group/podcasters>"

>    on the web.

>

>    -  To unsubscribe from this group, send an email to:

>    

podcasters-unsubscribe@yahoogroups.com<podcasters-unsubscribe@yahoogroups.com?su\

bject=Unsubscribe>

>

>    -  Your use of Yahoo! Groups is subject to the Yahoo! Terms of

>    Service <http://docs.yahoo.com/info/terms/>.

>

>

>  ------------------------------

>





[Non-text portions of this message have been removed]