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

[RichieWhite]

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

thanks,

Richie

[sxijam]

hehehe

[Owainnorth]

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.

[BKBK]

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.

[Owainnorth]

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.

[BKBK]

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)

[Owainnorth]

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.

[BKBK]

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

[Owainnorth]

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.

[BKBK]

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.

[Adam Cameron.]

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

[BKBK]

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.

[BKBK]

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.

[Owainnorth]

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.