> Okay, but what does appending the file type as a query string help? As far > as I can tell it only break stuff because people use your pop-up link > generator which has links like <URL: > http://www.michaelverdi.com/popup.php?url=http://michaelverdi.com/video/dresscode.mov > > that are not media links, but links to HTML pages.
Nope.. this is why I created the popup link generator thingie. It uses the popup URL for the onclick handler, but the href attribute is still the direct link to the media file and that direct link is what gets enclosed in the RSS feed. But this has little to do with the conversation here... -Josh On 3/17/06, Andreas Haugstrup <[EMAIL PROTECTED]> wrote: > Okay, but what does appending the file type as a query string help? As far > as I can tell it only break stuff because people use your pop-up link > generator which has links like <URL: > http://www.michaelverdi.com/popup.php?url=http://michaelverdi.com/video/dresscode.mov > > that are not media links, but links to HTML pages. > > Here's the deal: > > - Most people will just have the file name. Normal procedures can be > followed (first HTTP header, then filename and if content-type is > text/plain and filename is .mp4 it's probably a misconfigured server and > MP¤ should be assumed) > > - Some people will use query strings. This is usually serverside script > pushing out the file. If there is a filename it can't be trusted. The > content-type HTTP header can be trusted because people who are clever > enough to pipe videos through a script are clever enough to have the > script send the correct content-type header. > > - Feedburner already has the file extension correct (.mp4) in their > enclosures. As long as the URL is seperated into approciate parts before > parsing this is a non-issue. > > So what's the point in adding new arguments to the query string? As far as > I can tell this thing was proposed because of a faulty script that didn't > parse URLs for the filename properly. Call me a weirdo, but I prefer > fixing that one script instead of forcing those of us who want to pipe > stuff trough scripts to write URLs a certain way. > > And I'll shut up now. Promise. > > - Andreas > > On Fri, 17 Mar 2006 16:44:21 +0100, Joshua Kinberg <[EMAIL PROTECTED]> > wrote: > > > Here's my take... it would be great if mime-types solved the problem > > and if the enclosure "type" attribute was always present and always > > accurate. These things are not true in the wild world of RSS feeds. > > The best and most consistent indicator of a file type based on what > > people actually do is the file extension. It certainly would make > > things easier if the URL contained an extension at the end... even if > > it doesn't technically require it. Its not very hard to include > > &type=.mp4 (or similar) at the end of a redirect URL since that URL is > > completely arbitrary anyway. > > > > That said, we're working on a solution to this problem that will be > > available in the next release of FireAnt for Windows (FireAnt for Mac > > handles it fine). > > > > -Josh > > > > > > On 3/17/06, Andreas Haugstrup <[EMAIL PROTECTED]> wrote: > >> On Fri, 17 Mar 2006 14:35:35 +0100, Michael Sullivan > >> <[EMAIL PROTECTED]> wrote: > >> > >> > it's like this.... tell me if including the media file name, as i > >> > suggest, > >> > breaks anything. tell me if it makes a url worse. tell me that it > >> > makes no > >> > sense to include the file name. tell me something to convince me that > >> > this > >> > suggestion is illogical without telling me 'its not a problem so why > >> fix > >> > it'. > >> > >> You're coming at this from the wrong angle. > >> > >> We have URLs and we have HTTP. Well-defined standards and they have been > >> in use for almost 10 years. You want to change the way the URL work, > >> which > >> breaks backwards compatibility and *I* am supposed to give you more > >> reasons not to go ahead? No, you should give *me* a good reason why > >> redefining the meaning of the URL parts is a good idea. Why should we > >> all > >> spend time implementing this change when the current system has the same > >> capabilities? > >> > >> Why is this change needed? > >> How will it break old webpages? > >> How will differences between the filename part of the URL and the > >> filename > >> given in the query string be handled? > >> > >> The change you're proposing is not simple at all. I still don't know > >> *why* > >> you want this change. Is it because you're having trouble determining > >> mime > >> type? In that case use an HTTP library that follows the same standard as > >> everyone else have been using for the past 10 years - problem solved. No > >> need for the rest of the world to change. In my last mail I listed the 3 > >> step process required to determine a mime type in today's web - it's > >> not a > >> hard thing to do. Or do you have some other reason for proposing the > >> changes? > >> > >> -- > >> Andreas Haugstrup Pedersen > >> <URL: http://www.solitude.dk/ > > >> Commentary on media, communication, culture and technology. > >> > >> > >> > >> Yahoo! Groups Links > >> > >> > >> > >> > >> > >> > >> > > > > > > Yahoo! Groups Links > > > > > > > > > > > > -- > Andreas Haugstrup Pedersen > <URL: http://www.solitude.dk/ > > Commentary on media, communication, culture and technology. > > > > Yahoo! Groups Links > > > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/videoblogging/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
