Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Reply-To: <ajack@TrySybase.com>
From: "Adam Jack" <ajack@TrySybase.com>
To: "'Jakarta Commons Users List'" <commons-user@jakarta.apache.org>
Subject: [VFS] [PATCH] UrlFileObject.exists (when HTTP) 
Date: Thu, 8 May 2003 12:12:29 -0600
Message-ID: <033f01c3158d$654b46b0$b6d3ea43@wdn086>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <008901c30fdd$315b6c50$e2d9ea43@wdn086>

Ok, from the latest CVS code I see this in UrlFileObject:

    protected FileType doGetType() throws Exception
    {
        // Attempt to connect
        try
        {
            url.openConnection().connect();
        }
        catch ( final FileNotFoundException e )
        {
            return FileType.IMAGINARY;
        }
        return FileType.FILE;
    }

This is effectively (I believe) just testing that the server exists. I see
it is attempting to catch the FileNotFoundException, but I don't think that
is kicking in without attempting to access the content. Adding these lines
to extract the response code (and looking for a 200) seems to help for HTTP.
I am sure there are imperfections to do with some other return types being
valid (and personally I'd love to see use of URL replaced with HttpClient
and with a user-agent set, etc.) but I believe it is a step closer to
correct. Directory redirects and such might mess with it, but I *think* the
default follow redirects copes w/ those.

[BTW: I don't know if this code is ever used on local files, but I believe
that code path ought not be affected by my changes.]

    /**
     * Determines the type of the file.
     */
    protected FileType doGetType()
    {
        FileType fileType = FileType.FILE;
        // Attempt to connect & check status
        try
        {
            URLConnection conn = url.openConnection();
            conn.connect();
            if (conn instanceof HttpURLConnection)
            {
                int status = ((HttpURLConnection)conn).getResponseCode();
                // 200 is good, maybe add more later...
                if ( HttpURLConnection.HTTP_OK != status)
                    fileType = FileType.IMAGINARY;
            }
        }
        catch (final Exception e)
        {
            fileType = FileType.IMAGINARY;
        }
        return fileType;
    }

I am sorry this isn't a CVS patch, I've not learned how to do that yet, but
would a Commons VFS committer please look at this for me?

regards

Adam
-----Original Message-----
From: Adam Jack [mailto:ajack@trysybase.com]
Sent: Thursday, May 01, 2003 6:29 AM
To: 'Jakarta Commons Users List'
Subject: RE: [VFS] FileObject.exists (when HTTP) seems not to work as
expected...


	> Basically I get "true" even when the object fails to exist. Anybody else
	> seen this? Is it me, or ought I attempt to log a bug report?

	I'm seeing the same problem.  It's a bug.

Hmm, I went to try to log an issue, created an account, was told I didn't
have permission for the module, and then could not find a role to request
that seems appropriate for commons VFS.

	http://scarab.werken.com/scarab/issues/

Any hints on how I log this?

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org