ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Sinclair (JIRA)" <j...@apache.org>
Subject [jira] Created: (IVY-979) Support for URL's with unknown content length in URLResolver
Date Thu, 27 Nov 2008 20:40:44 GMT
Support for URL's with unknown content length in URLResolver
------------------------------------------------------------

                 Key: IVY-979
                 URL: https://issues.apache.org/jira/browse/IVY-979
             Project: Ivy
          Issue Type: Improvement
          Components: Core
    Affects Versions: 2.0-RC2
            Reporter: Jeffrey Sinclair
            Priority: Minor


Original email thread sent to ivy-users:

I've been trying to use the URLResolver with a custom protocol that
returns -1 for URLConnection.getContentLength(). The problem I'm seeing
is that for my custom protocol, resources can never be found.

After a little debugging I found the following code in
org.apache.ivy.util.url.BasicURLHandler.getURLInfo() which explains why
I'm running into issues:


    public URLInfo getURLInfo(URL url, int timeout) {

...
            if (con instanceof HttpURLConnection) {
               ...
            } else {

                int contentLength = con.getContentLength();

                if (contentLength <= 0) {

                    return UNAVAILABLE;

                } else {

                   ...
                }

            }

        } 

Is this a bug in the URLResolver? For certain resources which are
streamed, the content length will not be known so I'm not sure that
UNAVAILABLE should be dependent on the content length.

Additional comment:

It's unclear how an unknown content length should be supported because there appears to be
no standard way to determine if a resource is unavailable. I wrote a quick patch for Ivy which
involved checking for availability by trying to open an InputStream from the URLConnection
and seeing if an IOException is thrown. This is not ideal but worked as a workaround when
the content length was -1. 

This is not a critical issue that I personally need fixing because I've updated my custom
protocol to return the content length, however it is something to be aware of since a content
length of -1 means unknown rather than unavailable.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message