commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@TrySybase.com>
Subject RE: [VFS] [PATCH] UrlFileObject.exists (when HTTP)
Date Thu, 15 May 2003 04:53:23 GMT
I think you are right, HEAD is a better approach. It may not be supported by
all servers, but it is (IMHO) worth trying with, like you said, a fall back
approach to GET). An bunch of unsuccessful HEADs are probably less
inefficient that a bunch of successful GETs were the data is thrown away.

BTW: I'm getting report that my patch (and maybe your one later for
getLastModified) are leading to stray sockets (at least w/ a HotSpot VM).
I'm going to investigate to see if better clean-up is needed.

That said, I wonder if we could totally rework UrlFileObject to have access
the URLConnection once only (or once HEAD, once GET) and store
information/contents locally, to attempt efficiency and not leaving
connections open.

regards

Adam
-----Original Message-----
From: Anthony Eden [mailto:me@anthonyeden.com]
Sent: Thursday, May 08, 2003 1:40 PM
To: Jakarta Commons Users List
Subject: Re: [VFS] [PATCH] UrlFileObject.exists (when HTTP)


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


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