<!--- 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">

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>

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

Dave Watts wrote:
> I got NO NO NO.

I am curious what others got!

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

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

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

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

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

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.

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.

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.

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.

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

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.