Community
Participate
Working Groups
I am testing the latest ECF with Eclipse Memory Analyzer and p2 updates by running them from Eclipse IDE with bundles org.eclipse.ecf.provider.filetransfer 3.2.800.qualifier and org.eclipse.ecf.provider.filetransfer.efs 1.5.201.qualifier This is without any of the httpclient4 httpclient45 httpclient5 or httpclientjava plugins enabled. I noticed that when I had an update site such as http://download.eclipse.org/mat/1.13.0/update-site/ then I got a failure such as: HTTP Moved Permanently: http://download.eclipse.org/mat/1.13.0/update-site/content.xml HTTP Moved Permanently: http://download.eclipse.org/mat/1.13.0/update-site/content.xml General connection error with response code=301 and header(0)=HTTP/1.1 301 Moved Permanently because download.eclipse.org is redirecting to the https version and URLConnection doesn't follow http->https redirection. I think it would be better if there was the cause of the BrowseFileTransferException was a HttpRetryException with a location of the "Location" header of the response, a message of the first line of the response and the appropriate response code. It seems that the following codes could have a location header. } else if (code == HttpURLConnection.HTTP_MOVED_PERM || code == HttpURLConnection.HTTP_MOVED_TEMP || code == HttpURLConnection.HTTP_SEE_OTHER || code == HttpURLConnection.HTTP_NOT_MODIFIED || code == 307 || code == 308) { The caller could then handle the redirection and note the new URL, particularly for HTTP_MOVED_PERM. If runRequest did the retry then the caller wouldn't know about the new URL.
Hi Andrew, First, thanks for the efforts here. (In reply to Andrew Johnson from comment #0) > I am testing the latest ECF with Eclipse Memory Analyzer and p2 updates by > running them from Eclipse IDE with bundles > org.eclipse.ecf.provider.filetransfer 3.2.800.qualifier and > org.eclipse.ecf.provider.filetransfer.efs 1.5.201.qualifier > > This is without any of the httpclient4 httpclient45 httpclient5 or > httpclientjava plugins enabled. Why not use one of these for testing...as these (httpclient5 and httpclientjava) are the current and likely future ones to be maintained (for Eclipse and p2). > > I noticed that when I had an update site such as > http://download.eclipse.org/mat/1.13.0/update-site/ then I got a failure > such as: > > HTTP Moved Permanently: > http://download.eclipse.org/mat/1.13.0/update-site/content.xml > HTTP Moved Permanently: > http://download.eclipse.org/mat/1.13.0/update-site/content.xml > General connection error with response code=301 and header(0)=HTTP/1.1 301 > Moved Permanently > > because download.eclipse.org is redirecting to the https version and > URLConnection doesn't follow http->https redirection. Does httpclient or httpclientjava follow http->https redirection? > > I think it would be better if there was the cause of the > BrowseFileTransferException was a HttpRetryException with a location of the > "Location" header of the response, a message of the first line of the > response and the appropriate response code. > > It seems that the following codes could have a location header. > } else if (code == HttpURLConnection.HTTP_MOVED_PERM || code == > HttpURLConnection.HTTP_MOVED_TEMP || code == > HttpURLConnection.HTTP_SEE_OTHER || code == > HttpURLConnection.HTTP_NOT_MODIFIED || code == 307 || code == 308) { > > The caller could then handle the redirection and note the new URL, > particularly for HTTP_MOVED_PERM. If runRequest did the retry then the > caller wouldn't know about the new URL. I accept that this may be better...but I submit that it might not be worth it if it only applies to the URLConnection handler based provider. If it can be applied to the most recent providers (httpclient5 and httpclientjava) then yes I would agree, but I don't know that it's worth doing just for the URLConnection provider (which is limited in other ways and very old now). OTOH if you are willing to change the code and provide a junit test I'll add it even if it's just for the URLConnection-based provider.
