commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Eden ...@anthonyeden.com>
Subject Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Date Thu, 08 May 2003 19:40:07 GMT
It might be interesting to use the HEAD method instead of the default of GET so that the entire
content is not loaded.  The only thing I don't know is whether or not all servers support
the HEAD method.  You may have to check for unsupported method errors and then try a GET if
the HEAD fails.  Of course all of this might be overkill, I am not sure.

Sincerely,
Anthony Eden

Adam Jack wrote:
> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message