Hi all, I am new to this forum and basically working through a tutorial.<br />
<br />
I am having a problem understanding how to differentiate between creating a normal link (like a link to some jpeg that just opens up in your browser window) and creating a Download <!--more--> link to a similar resource.<br />
<br />
For example:<br />
<a href=http://www.webdeveloper.com/forum/archive/index.php/"http://www.pvv.ntnu.no/~madsb/jc/images/files/Folio/Later/jc_by_mk.sized.jpg">connelly link</a><br />
<br />
This creates a link that opens up the jennifer connelly pic in your browser window......My question is how do you create a link that would enable you to actually have this pic Download <!--more-->ed when the link is clicked.<br />
<br />
Is the ftp protocol involved? I have viewed source code on mpeg links and they seem to have the same <a href> formula but sometimes the link is a Download <!--more-->able one and sometimes it just plays in your browser window. Any help would be appreciated. thanks.<!--content-->generally jpg's and mpg's will open up when you click on them. If want want a user to Download <!--more--> the picture to a specific spot you could also have them 'right click' the picture and then select Save as.. to Download <!--more--> it. I don't think there is a tag for allowing people to Download <!--more--> a link specifically.<br />
<br />
<br />
nuffsaid<!--content-->their isnt sadly I wish there were a Download <!--more--> maybe a target attribute. Wouldnt that be nice target="_doanload" or something. Hummm If they ever were to come out with a new html I bet it would do that...<!--content-->Originally posted by nuffsaid420 <br />
I don't think there is a tag for allowing people to Download <!--more--> a link specifically. It isn't a tag, but there is a way. Though, I understand that it doesn't work on MSIE. <br />
<br />
Servers create for each file on the internet what is called the HTTP response header. This is not the document's HEAD element, nor is it the packet header. This header looks something like:<br />
<br />
HTTP/1.1 200 OK<br />
Date: Mon, 16 Jun 2003 09:56:38 GMT<br />
Server: Apache/1.3.27 (Unix) PHP/4.1.2 mod_oas/5.1.2 mod_cap/1.0<br />
X-Powered-By: PHP/4.1.2<br />
Set-Cookie: RMID=8d9d3e8c3eed9450; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.webdeveloper.com<br />
~~~~~~~~~~~~~~: ~~~~~<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
The header might also contain the size of the file and its expiration date. The browser can request just this header and then decide if it really needs to Download <!--more--> it or if the copy it Download <!--more-->ed last time is still valid. This is how caching works. But note that last line. It tells browsers what kind of file it is and browsers are supposed to send the file to the proper application. If you can change it to something that the browser doesn't know how to handle then it will simply save it to the disk. Hence:<br />
<br />
Content-Type: application/octet-stream<br />
<br />
Talk to your server folks about how to manipulate the response headers. And it's a nice touch to indicate the content type in the link itself:<br />
<br />
<a href=http://www.webdeveloper.com/forum/archive/index.php/"someFile.png" type="application/octet-stream">someFile</a><br />
<br />
But MSIE will ignore the international standard and will handle the file according to the file extension in its name. If you don't want to "zip" the file then you can change the name to something like "someFile.xxx".<!--content-->As I noted in my post, I had been informed that it was MSIE that erroniously handled the Content-Type header. It seems that I was misinformed and I stand (well sit actually, on a big red ball) corrected. Thank you.<br />
<br />
Just to be clear, though. There is nothing in the specifications that requires a browser to recognize the "type" attribute of the A element. But it would be nice.<!--content-->So back to Download <!--more-->s. Look like you might end up zipping the file.<!--content-->I dont mean to beat a dead horse here but i still have a few more questions on this topic.<br />
<br />
So when the server sends the content type of the file to the browser, is the browser going to try to open the file up in the browser window using the appropriate application that is set in MY COMPUTER:FOLDER OPTIONS:FILE TYPES or basically whatever appliation has been set to open up certain file types as has been configured?<br />
<br />
Also, how do stand-alone players like quicktime and media player interact with the browser to act as plug-ins....are they automatically configured as plug-ins during the normal installation process?<br />
<br />
Let's say that i didnt have the correct application to play a certain file that i was attempting to Download <!--more-->.....would the result be that the file would be automatically Download <!--more-->ed instead of being played in the browser, or would i be prompted to Download <!--more--> the plug-in required to play the file.....or am i just totally confusing these concepts??<br />
<br />
I was experimenting to see what happened with different files that i tried to Download <!--more--> and got the results below:<br />
.mp3,.mov,.mpg(Quicktime tries to play it in browser window)<br />
rm(real player tries to play in window)<br />
wmv,avi,asf(windows media player tries to play in window)<br />
<br />
.wma was the only file type that i tried that would give me the Download <!--more--> option<!--content-->ok its not going to give you Download <!--more--> link if ie can handle it. Its only files a browser cant handle. Like a .zip or what you said a .wma, so if you have image you want people to doanload you better zip them because the majority of users are on ie and this Download <!--more--> link trick charles and dave are talking about will not work unless you use it with a server side language like asp to talk to the browser from what I got. So zip your images and that will work thats a proven method.<!--content-->It sounds like you are being confused by how links react in diferent situations. The first thing to realize is that there are different ways of getting to the same place...and different ways of utilizing a link.<br />
<br />
Very often there is a user agent (browser) and server interaction that dictates a reaction from your browser and how to deal with a target, (which was being discussed). <br />
<br />
Not that I can explain your questions fully, but let me clear up some confusion in the second paragraph of your second post.<br />
<br />
Let's say you have a link to an audio file (ie X.MP3) on your site. Different servers will handle this different ways. Some might have a Download <!--more--> prompt, and others might turn your browser window to jibberish (maybe due to file size limits, multimedia restrictions, etc) either way I think the recognition is done on their end. I say this because I have some music on one server that turns the browser to jibberish, yet works ok on another server.<br />
<br />
Now that exact same audio file (X.MP3) would play perfectly if you create a stub file for the link, which is nothing more than a standard text file containing the url of the actual audio file, with a ".M3U" file extension on it. A ".M3U" file extension is the standard file extension for playlists, therefore if you click on a link to a ".M3U" file extension, the browser Download <!--more-->s that link (which is nothing more than a 1k text file with the actual url in it) and then hands it off to whatever application your computer has set up as default for that type of file, whether it be musicmatch, WMP, winamp, etc. The same holds true for real media. if the stub file contained a .RAM file (containing the url of the actual .RM audio file), it would Download <!--more--> the 1k file and then hand it off to Real Player, and BAAMMM....streaming on a budget. It only takes a second to Download <!--more--> the text file and the application is then told to go out and retrieve the audio file and start playing.<br />
<br />
Hopefully this clears up the questions in your second paragraph. As far as how to make a photo give a "Download <!--more-->" prompt on click I'm not too sure personally but try not to confuse it with which application is going to handle a link etc. <br />
<br />
There are different ways to handle things.<!--content-->hastx that could quite possibly be the most confusing thing I have read in a week. thanks
<!--content-->Originally posted by PeOfEo <br />
hastx that could quite possibly be the most confusing thing I have read in a week. thanks <br />
<br />
LOL I should have just said "contact your server administrator" <br />
<br />
Its just that I had some of the same questions when I first started making music available for Download <!--more-->. The exact same files and exact same webpages would react differently on different hosts that i tried. when clicking on the link, one host would turn the browser to jibeerish, and another would prompt for Download <!--more-->. i figured it had to be a server configuration issue or limitation. Then I learned the stub file trick and at least that reacted the same.<!--content-->well thats one round about way of saying it lol.<!--content-->
<br />
I am having a problem understanding how to differentiate between creating a normal link (like a link to some jpeg that just opens up in your browser window) and creating a Download <!--more--> link to a similar resource.<br />
<br />
For example:<br />
<a href=http://www.webdeveloper.com/forum/archive/index.php/"http://www.pvv.ntnu.no/~madsb/jc/images/files/Folio/Later/jc_by_mk.sized.jpg">connelly link</a><br />
<br />
This creates a link that opens up the jennifer connelly pic in your browser window......My question is how do you create a link that would enable you to actually have this pic Download <!--more-->ed when the link is clicked.<br />
<br />
Is the ftp protocol involved? I have viewed source code on mpeg links and they seem to have the same <a href> formula but sometimes the link is a Download <!--more-->able one and sometimes it just plays in your browser window. Any help would be appreciated. thanks.<!--content-->generally jpg's and mpg's will open up when you click on them. If want want a user to Download <!--more--> the picture to a specific spot you could also have them 'right click' the picture and then select Save as.. to Download <!--more--> it. I don't think there is a tag for allowing people to Download <!--more--> a link specifically.<br />
<br />
<br />
nuffsaid<!--content-->their isnt sadly I wish there were a Download <!--more--> maybe a target attribute. Wouldnt that be nice target="_doanload" or something. Hummm If they ever were to come out with a new html I bet it would do that...<!--content-->Originally posted by nuffsaid420 <br />
I don't think there is a tag for allowing people to Download <!--more--> a link specifically. It isn't a tag, but there is a way. Though, I understand that it doesn't work on MSIE. <br />
<br />
Servers create for each file on the internet what is called the HTTP response header. This is not the document's HEAD element, nor is it the packet header. This header looks something like:<br />
<br />
HTTP/1.1 200 OK<br />
Date: Mon, 16 Jun 2003 09:56:38 GMT<br />
Server: Apache/1.3.27 (Unix) PHP/4.1.2 mod_oas/5.1.2 mod_cap/1.0<br />
X-Powered-By: PHP/4.1.2<br />
Set-Cookie: RMID=8d9d3e8c3eed9450; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.webdeveloper.com<br />
~~~~~~~~~~~~~~: ~~~~~<br />
Connection: close<br />
Content-Type: text/html<br />
<br />
The header might also contain the size of the file and its expiration date. The browser can request just this header and then decide if it really needs to Download <!--more--> it or if the copy it Download <!--more-->ed last time is still valid. This is how caching works. But note that last line. It tells browsers what kind of file it is and browsers are supposed to send the file to the proper application. If you can change it to something that the browser doesn't know how to handle then it will simply save it to the disk. Hence:<br />
<br />
Content-Type: application/octet-stream<br />
<br />
Talk to your server folks about how to manipulate the response headers. And it's a nice touch to indicate the content type in the link itself:<br />
<br />
<a href=http://www.webdeveloper.com/forum/archive/index.php/"someFile.png" type="application/octet-stream">someFile</a><br />
<br />
But MSIE will ignore the international standard and will handle the file according to the file extension in its name. If you don't want to "zip" the file then you can change the name to something like "someFile.xxx".<!--content-->As I noted in my post, I had been informed that it was MSIE that erroniously handled the Content-Type header. It seems that I was misinformed and I stand (well sit actually, on a big red ball) corrected. Thank you.<br />
<br />
Just to be clear, though. There is nothing in the specifications that requires a browser to recognize the "type" attribute of the A element. But it would be nice.<!--content-->So back to Download <!--more-->s. Look like you might end up zipping the file.<!--content-->I dont mean to beat a dead horse here but i still have a few more questions on this topic.<br />
<br />
So when the server sends the content type of the file to the browser, is the browser going to try to open the file up in the browser window using the appropriate application that is set in MY COMPUTER:FOLDER OPTIONS:FILE TYPES or basically whatever appliation has been set to open up certain file types as has been configured?<br />
<br />
Also, how do stand-alone players like quicktime and media player interact with the browser to act as plug-ins....are they automatically configured as plug-ins during the normal installation process?<br />
<br />
Let's say that i didnt have the correct application to play a certain file that i was attempting to Download <!--more-->.....would the result be that the file would be automatically Download <!--more-->ed instead of being played in the browser, or would i be prompted to Download <!--more--> the plug-in required to play the file.....or am i just totally confusing these concepts??<br />
<br />
I was experimenting to see what happened with different files that i tried to Download <!--more--> and got the results below:<br />
.mp3,.mov,.mpg(Quicktime tries to play it in browser window)<br />
rm(real player tries to play in window)<br />
wmv,avi,asf(windows media player tries to play in window)<br />
<br />
.wma was the only file type that i tried that would give me the Download <!--more--> option<!--content-->ok its not going to give you Download <!--more--> link if ie can handle it. Its only files a browser cant handle. Like a .zip or what you said a .wma, so if you have image you want people to doanload you better zip them because the majority of users are on ie and this Download <!--more--> link trick charles and dave are talking about will not work unless you use it with a server side language like asp to talk to the browser from what I got. So zip your images and that will work thats a proven method.<!--content-->It sounds like you are being confused by how links react in diferent situations. The first thing to realize is that there are different ways of getting to the same place...and different ways of utilizing a link.<br />
<br />
Very often there is a user agent (browser) and server interaction that dictates a reaction from your browser and how to deal with a target, (which was being discussed). <br />
<br />
Not that I can explain your questions fully, but let me clear up some confusion in the second paragraph of your second post.<br />
<br />
Let's say you have a link to an audio file (ie X.MP3) on your site. Different servers will handle this different ways. Some might have a Download <!--more--> prompt, and others might turn your browser window to jibberish (maybe due to file size limits, multimedia restrictions, etc) either way I think the recognition is done on their end. I say this because I have some music on one server that turns the browser to jibberish, yet works ok on another server.<br />
<br />
Now that exact same audio file (X.MP3) would play perfectly if you create a stub file for the link, which is nothing more than a standard text file containing the url of the actual audio file, with a ".M3U" file extension on it. A ".M3U" file extension is the standard file extension for playlists, therefore if you click on a link to a ".M3U" file extension, the browser Download <!--more-->s that link (which is nothing more than a 1k text file with the actual url in it) and then hands it off to whatever application your computer has set up as default for that type of file, whether it be musicmatch, WMP, winamp, etc. The same holds true for real media. if the stub file contained a .RAM file (containing the url of the actual .RM audio file), it would Download <!--more--> the 1k file and then hand it off to Real Player, and BAAMMM....streaming on a budget. It only takes a second to Download <!--more--> the text file and the application is then told to go out and retrieve the audio file and start playing.<br />
<br />
Hopefully this clears up the questions in your second paragraph. As far as how to make a photo give a "Download <!--more-->" prompt on click I'm not too sure personally but try not to confuse it with which application is going to handle a link etc. <br />
<br />
There are different ways to handle things.<!--content-->hastx that could quite possibly be the most confusing thing I have read in a week. thanks
<!--content-->Originally posted by PeOfEo <br />hastx that could quite possibly be the most confusing thing I have read in a week. thanks
<br /><br />
LOL I should have just said "contact your server administrator"
<br /><br />
Its just that I had some of the same questions when I first started making music available for Download <!--more-->. The exact same files and exact same webpages would react differently on different hosts that i tried. when clicking on the link, one host would turn the browser to jibeerish, and another would prompt for Download <!--more-->. i figured it had to be a server configuration issue or limitation. Then I learned the stub file trick and at least that reacted the same.<!--content-->well thats one round about way of saying it lol.<!--content-->