DownloadResult does not contain the headers sent with the artifact
The DownloadResult contains the file that was downloaded, but it does not contain headers that were returned with it. Some content types, such as Docker Manifests, could really benefit from having this information available when creating content units from the downloaded artifacts.
#4 Updated by bmbouter over 1 year ago
Currently, the DownloadResult is protocol independent. Adding HTTP headers seems inappropriate. Perhaps the DownloadResult should be a class and the HttpDownloader should return an HttpDownloadResult subclass that includes the headers.
The practical issue with this approach is that plugin writers don't want a polymorphic experience. For example, if some DownloadResult objects have an attribute named e.g. 'headers' and others don't then the plugin writer dealing with the result always has to be concerned for this. Note that the user is providing the url which dictates the types of result the pluign writer would have to deal with, so together this means all plugin writer's would have to worry about this.
Having FileDownloader return a DownloadResult with 'headers' being empty is ok since there is no data there, and it gives plugin writers a consistent interface to use.
#5 Updated by firstname.lastname@example.org over 1 year ago
- Status changed from ASSIGNED to POST
- Assignee set to email@example.com
@jortel, I agree with what you are saying. However, I decided that it will be simpler for the FIleDownloader to return DownloadResults with headers set to None rather than create 2 types of DownloadResults for plugin writers to work with.
Please register to edit this issue