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, 15 May 2003 14:49:35 GMT
Adam,

Based on my understanding of the URLConnection class we will need to get 
the InputStream after opening the connection and then make sure that 
that stream is closed in the finally block.   I have attached a diff of 
changes against the current code.

Sincerely,
Anthony Eden

Adam Jack wrote:

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