Skip navigation
RichieWhite
Currently Being Moderated

Can I test to see if a remote url file exists?

Dec 14, 2010 1:27 PM

I need to check to see if an mp3 file exists on a remote server. Can someone help me with this code?

 

thanks,

Richie

 
Replies
  • Currently Being Moderated
    Dec 14, 2010 1:35 PM   in reply to RichieWhite

    <cfhttp....> to the url of the MP3 on the server.  Using the head option if you don't want to download the actual MP3 file.

     

    A status 200 ok in the returned structer of the <cfhttp...> call would indicate that it exists, or at least something exists, at that url.

    You may want to investigate other information in the returned structure to confirm that it is the specific desired content.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 14, 2010 1:37 PM   in reply to RichieWhite

    <!--- Head method is same as Get method, but here, server doesn't send back any response. We only need to check whether file exists --->
    <cfhttp method="head" url="url_of_the_mp3_file">

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 14, 2010 1:38 PM   in reply to BKBK

    I reacted before seeing the last post.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 14, 2010 1:51 PM   in reply to RichieWhite

    It is not going to return a yes or no.  It is going to return a structure.  YOu then examin that structure to determine if it was a yes or no.

     

    As BKBK showed

     

    <cfhttp method="head" url="http://www.myurl.com/mymp3.mp3">
    ...
    <cfdump var="#cfhttp#">

     

    You would then be looking for a "200 OK" status.  200 OK is the HTTP status that the URL was found and returned what was requested.

     

    <cfhttp...> documentation.

    http://livedocs.adobe.com/coldfusion/8/htmldocs/Tags_g-h_09.html

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 14, 2010 1:58 PM   in reply to RichieWhite

    RichieWhite wrote:

     

     

    How would I get ... a yes or a no?

    You might decide to push the envelope, and do something like this instead:

     

    <cfoutput>#fileExists("http://www.myurl.com/mymp3.mp3")#</cfoutput>

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 14, 2010 2:15 PM   in reply to BKBK

    That seems to push the envelope beyond the limit of possibility.

     

    CF8 Documentation

     

    fileExists Parameters

    Parameter

    Description

    absolute_path

    An absolute path

     

    CF9 Documentation

    fileExists Parameters

    Parameter

    Description

    absolute_path

    The absolute path of the on-disk or in-memory file.

     

    They seem to be pretty adamant that a URL is not an allowed value for the parameter.

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Dec 14, 2010 2:20 PM   in reply to ilssac

    While it doesn't work, it also doesn't error - it just always returns false!

     

    Dave Watts, CTO, Fig Leaf Software

    http://www.figleaf.com/

    http://training.figleaf.com/

     

    Read this before you post:

    http://forums.adobe.com/thread/607238

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 15, 2010 11:17 AM   in reply to Dave Watts

    Dave Watts wrote:

     

    While it doesn't work, it also doesn't error - it just always returns false!

     

     

    Dave Watts, CTO, Fig Leaf Software

    http://www.figleaf.com/


    OK. So, let's take your own web site. Put this in your pipe and light up:

     

    fileExists("http://www.figleaf.com/"): <cfoutput>#fileExists("http://www.figleaf.com/")#</cfoutput><br>
    fileExists("http://www.figleaf.com/images/topbanner_products.jpg"): <cfoutput>#fileExists("http://www.figleaf.com/images/topbanner_products.jpg")#</cfoutput><br>
    fileExists("http://www.figleaf.com/images/bkbk_test.jpg"): <cfoutput>#fileExists("http://www.figleaf.com/images/bkbk_test.jpg")#</cfoutput>

     

    You should get (on CF9 at any rate):

     

    yes

    yes

    no

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Dec 15, 2010 10:12 PM   in reply to BKBK

    I don't smoke a pipe. But more importantly, I got NO NO NO. That's basically the test I tried before posting my response - I didn't know whether it would work or not. I'm running CF 9 on Windows x64, full JRun install.

     

    Dave Watts, CTO, Fig Leaf Software

    http://www.figleaf.com/

    http://training.figleaf.com/

     

    Read this before you post:

    http://forums.adobe.com/thread/607238

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 1:45 AM   in reply to Dave Watts

    Dave Watts wrote:
    > I got NO NO NO.

     

    I am curious what others got!

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 4:17 AM   in reply to BKBK

    Even I got NO NO NO; I m working in CF 9


     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 5:18 AM   in reply to BKBK

    I got the same results you did, BKBK:  Yes | Yes | No

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 6:38 AM   in reply to BKBK

    Add me to the tripple NO club.

     

    fileExists("http://www.figleaf.com/"): NO
    fileExists("http://www.figleaf.com/images/topbanner_products.jpg"): NO
    fileExists("http://www.figleaf.com/images/bkbk_test.jpg"): NO

     

    productversion 9,0,0,251028

     
    |
    Mark as:
  • Dave Watts
    747 posts
    Mar 11, 2003
    Currently Being Moderated
    Dec 16, 2010 6:51 AM   in reply to BKBK

    Perhaps this is a 9.0.1 thing - I tested with 9.0.0 as I haven't upgraded this machine yet.

     

    Dave Watts, CTO, Fig Leaf Software

    http://www.figleaf.com/

    http://training.figleaf.com/

     

    Read this before you post:

    http://forums.adobe.com/thread/607238

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 9:43 AM   in reply to JMF

    JMF wrote:

     

    I got the same results you did, BKBK:  Yes | Yes | No

    Yey!

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 9:47 AM   in reply to Dave Watts

    Dave Watts wrote:

     

    Perhaps this is a 9.0.1 thing - I tested with 9.0.0 as I haven't upgraded this machine yet.

    Indeed. I am on build 9.0.1.274703

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 9:51 AM   in reply to BKBK

    BKBK wrote:

     

    Indeed. I am on build 9.0.1.274703

     

    So now the question is - Is this documented anywhere as an enhancement|change in 9.0.1?

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 16, 2010 11:26 AM   in reply to Dave Watts

    Yeah, that could be it.  I tested on a 9.0.1 installation.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 17, 2010 5:18 AM   in reply to JMF

    I tested with 9.0.1 and I get YES YES NO and there are a couple of

    interesting things:

     

    - cookies persist between function calls and page requests (in other

    words if www.google.com sets a cookie in one request it will be sent

    to google in subsequent page requests);

     

    - it caches the connection so if you have multiple fileExists checks

    it avoid opening and closing TCP connections;

     

    - the connection to the server is not closed when the page requests is

    completed (I think it stays open until the TCP timeout is reached).

     

    - seems to do an extra HEAD request (for example if you have a single

    fileExists the first HEAD request is done with "User-Agent: Jakarta

    Commons-HttpClient/3.1" and the "real" request is done with

    "User-Agent: Jakarta-Commons-VFS")

     

    Interesting.

     

    --

    Mack

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 17, 2010 5:29 AM   in reply to Dave Watts

    Yeah, URLs seem to work for me on 9.0.1, too.

     

    I'm not sure I'm convinced this is a sensible feature of fileExists(). Well it mostly seems OK, but something about it doesn't quite sit right for me. I guess it's because the operations to implement the "file system" side of things is completely different to that for checking URLs. And if I found myself writing a function which had two completely separate bits either side of an "else" statement, I'd start wondering if I was putting too much into the function.

     

    What does it do with 30x responses? Also, does it do a HEAD request, or a full GET? I presume it's the latter.

     

    Wouldn't it be nice if Adobe kept their docs up to date? Surely if someone had a ticket raised to "add this functionality to fileExists()", there should have also been a ticket to "update the documentation for fileExists()".

     

    Personally I think I would have preferred a urlExists() function, if they were going to do this.

     

    Still: bottom line is that it'll be handy for some people, so it's a good thing.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 17, 2010 5:45 AM   in reply to Adam Cameron.

    What does it do with 30x responses?

     

    Follows them.

     

    Also, does it do a HEAD request, or a full GET? I presume it's the latter.

     

    HEAD, although some servers treat that as a GET.

     

     

    Wouldn't it be nice if Adobe kept their docs up to date? Surely if someone had a ticket raised to "add this functionality to fileExists()", there should have also been a ticket to "update the documentation for fileExists()".

     

    I think this might have slipped in 9.0.1 with the support for Amazon

    S3 (for example fileOpen("http://www.google.com/") does a couple of

    head requests and then a GET request and then errors out with "Complex

    object types cannot be converted to simple values.").

     

    --

    Mack

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 17, 2010 9:46 AM   in reply to mack_

    I think this might have slipped in 9.0.1 with the support for Amazon

    S3

     

    Yeah, fair enough: that would make sense.

     

     

    (for example fileOpen("http://www.google.com/") does a couple of

    head requests and then a GET request and then errors out with "Complex

    object types cannot be converted to simple values.").

     

    Nice. Great feature that one.

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 18, 2010 7:42 PM   in reply to RichieWhite

    hehehe

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 1:26 AM   in reply to sxijam

    Well, good and thorough work from many people there, from which I think we can conclude:

     

      "Don't use functions for things they weren't intended"

     

    Personally I'd be sticking to the cfhttp suggested in the first post. Couldn't agree more with Adam though, that the inappropriately named "livedocs" should possibly be renamed as Adobe MoribundDocs. Very frustrating not having up-to-date documentation when it's needed.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 3:57 AM   in reply to Owain North

    Owainnorth wrote:

     

    Well, good and thorough work from many people there, from which I think we can conclude:

     

      "Don't use functions for things they weren't intended"

     

    Personally I'd be sticking to the cfhttp suggested in the first post.

     

    I should add a reminder here that I was merely making an experimental suggestion to test ColdFusion's capability. It's achieved one result: we've narrowed it down to CF9.0.1!

     

    Using cfhttp is naturally the most appropriate way to do it presently. However, it would be neat to officially have fileExists(arg:URL) in CF9.0.1 onwards.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 4:05 AM   in reply to BKBK

    Oh absolutely I see the point in testing, but doesn't fileExists(url) feel wrong to you? An url is *not* a file, the two are completely different things. If what we're saying is that a function urlExists would be handy, then surely that's just a cfhttp with a <cfreturn cfhttp.statuscode EQ 200 /> at the end?

     

    O.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 4:24 AM   in reply to Owain North

    Owainnorth wrote:

     

    Oh absolutely I see the point in testing, but doesn't fileExists(url) feel wrong to you? An url is *not* a file, the two are completely different things. If what we're saying is that a function urlExists would be handy, then surely that's just a cfhttp with a <cfreturn cfhttp.statuscode EQ 200 /> at the end?

     

    O.

    FileExists(url) feels perfectly right to me! In fact, in a roundabout way, File(url) already exists in ColdFusion, by virtue of java.io.File(java.net.URI)

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 4:38 AM   in reply to BKBK

    True it may exist in *java*, but that's not ColdFusion.

     

    To me it makes no more sense than having arraySort(queryset). ColdFusion is meant to be an easy-to-use development tool which is largely self-documenting due to the sensible naming of its functions.

     

    If you called fileExists("http://www.google.com"), what file is it actually testing? Because there's no filename in there. A web request responds on port 80 with a 200 status code, but that has nothing to do with files existing.

     

    In languages where it's the norm to have multiple function signatures I'd completely agree with you - most objects in .NET for example simply support the .sort() method. However historically that's not how CF has worked, it's been a function-based methodology with different functions for arrayClear() and structClear() for example; to change to having a clear(struct) and clear(array) methodology would be an unusual one I feel, certainly in such a loosely-typed platform.

     

    I agree there's no harm in fileExists working on a URI, but I'd just hate to see CF go the same way of the open-source alternatives such as PHP and MySQL, where the documentation available is significantly watered down by the number of aliases that the same functions have, which've been created simply for someone's convenience.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 4:59 AM   in reply to Owain North
    True it may exist in *java*, but that's not ColdFusion.

    It is ColdFusion. Here is it, in plain cfml: createobject("java","java.io.File").init(uri).

     

    It goes without saying that, when it comes to what is Java and what is ColdFusion, the lines have been blurred since the arrival of CF MX6. The rest of your comment hangs on the line I've just discussed, so I'll leave it here.

     

     

     

     

     

    edited: uri in place of url

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 5:01 AM   in reply to BKBK

    I disagree. CreateObject is undeniably ColdFusion, but the actual object you're creating and whose logic you're using to return the result of your test is *not*, it's java. In the same way I could probably use createObject("dotnet", "system.io.File").exists(uri), but that doesn't make it CF performing the logic, it's the .NET Framework.

     

    That's my only point. But still, if it works then it works.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 5:33 AM   in reply to Owain North

    I understand what you say, and agree in part. I think however that, by bringing in .NET, you push the analogy too far. Coldfusion is now a Java application. Most of its new functionality is in fact composed of wrappers of Java objects.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 8:54 AM   in reply to BKBK

    In fact, in a roundabout way, File(url) already exists in ColdFusion, by virtue of java.io.File(java.net.URI)

     

    Well no, it doesn't.  You're confusing the notion of a "URL" with that of a "URI".

     

    Also, if you read the docs @ that link you provide, it specifically states that it requires a FILE: URI.  So one cannot use java.io.File to access documents via HTTP.  java.io.File is for working with files on the local file system (where "local file system" could include network resources that the OS exposes as files & directories).

     

    --

    Adam

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 19, 2010 2:18 PM   in reply to Adam Cameron.

    Adam Cameron. wrote:

     

    In fact, in a roundabout way, File(url) already exists in ColdFusion, by virtue of java.io.File(java.net.URI)

     

    Well no, it doesn't.  You're confusing the notion of a "URL" with that of a "URI".

     

    Also, if you read the docs @ that link you provide, it specifically states that it requires a FILE: URI.  So one cannot use java.io.File to access documents via HTTP.  java.io.File is for working with files on the local file system (where "local file system" could include network resources that the OS exposes as files & directories).

     

    --

    Adam

    I've just popped in, have to pop out again. Seen your e-mail come in. Just a quick acknowledgement.

     

    I'm not confused about that, Adam. In fact, you will see that I had actually converted the argument from URL to URI.

     

    Just to refresh my memory, I've just checked an old file transfer project involving extensive use of java.io.File(URI). And there it was indeed. But I hear what you say. It just might be a conversion from network URLs to local URIs.. I'll look in detail later and report.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 20, 2010 12:56 AM   in reply to Owain North
    function(){return A.apply(null,[this].concat($A(arguments)))}

    function(){return A.apply(null,[this].concat($A(arguments)))}function(){return A.apply(null,[this].concat($A(arguments)))}

    Owainnorth wrote:

     

    Oh absolutely I see the point in testing, but doesn't fileExists(url) feel wrong to you? An url is *not* a file, the two are completely different things. If what we're saying is that a function urlExists would be handy, then surely that's just a cfhttp with a <cfreturn cfhttp.statuscode EQ 200 /> at the end?

     

     

    Adam Cameron. wrote:

     

    In fact, in a roundabout way, File(url) already exists in ColdFusion, by virtue of java.io.File(java.net.URI)

     

    Well no, it doesn't.  You're confusing the notion of a "URL" with that of a "URI".

     

    Also, if you read the docs @ that link you provide, it specifically states that it requires a FILE: URI.  So one cannot use java.io.File to access documents via HTTP.  java.io.File is for working with files on the local file system (where "local file system" could include network resources that the OS exposes as files & directories).

     


    I will stop right here. I am wrong on java.io.File(java.net.URI). I went just one experiment too far. Like Fleischmann and Pons, and their own Cold Fusion gaffe, I cannot wriggle out of this one.

     

    I have taken a detailed look at the code that had inspired me to think File(URI) was possible for any URI scheme. It isn't. What the code does is, get files from the web by filestreaming java.net.URL. Behind the scenes, the result is stored to disk and scheme-to-scheme converter is used to translate http:// URIs to corresponding file:// URIs. That part is not transparent, and that's what I had missed.

     

    My apologies to you Owain. Your suggestion urlExists() indeed stands as the correct suggestion to make along these lines.

     

    Thanks, Adam, for the correction. Sorry to have foiled the chance so early for one of our banters.

     
    |
    Mark as:
  • Currently Being Moderated
    Dec 20, 2010 1:02 AM   in reply to BKBK

    Hey it wasn't a suggestion on my part, it was a guess

     

    If only everyone was as thorough in their testing as you are sir, we'd have far fewer annoying "how does cfif work" posts to wade through.

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points