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

<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.

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

I reacted before seeing the last post.

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

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>

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

CF8 Documentation

fileExists Parameters

CF9 Documentation

fileExists Parameters

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

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

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

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

Dave Watts wrote:
> I got NO NO NO.

I am curious what others got!

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

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

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

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

JMF wrote:

 

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

Yey!

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

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?

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

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

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

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

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

hehehe

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.

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.

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.

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)

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.

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

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.

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.

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

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.

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.

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.