Issue #4061
DownloadResult does not contain the headers sent with the artifact
Description
The DownloadResult0 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.
Associated revisions
Revision 2fa951fb
View on GitHub
Problem: DownloadResult is missing response headers
Solution: Add response header to the DownloadResult
The HttpDownloader now adds the response headers to the DownloadResult.
Revision 2fa951fb
View on GitHub
Problem: DownloadResult is missing response headers
Solution: Add response header to the DownloadResult
The HttpDownloader now adds the response headers to the DownloadResult.
Revision 2fa951fb
View on GitHub
Problem: DownloadResult is missing response headers
Solution: Add response header to the DownloadResult
The HttpDownloader now adds the response headers to the DownloadResult.
History
#1
Updated by CodeHeeler about 1 year ago
- Triaged changed from No to Yes
- Sprint set to Sprint 44
#2
Updated by jortel@redhat.com about 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.
#3
Updated by dkliban@redhat.com 12 months ago
- Status changed from NEW to ASSIGNED
#4
Updated by bmbouter 12 months ago
jortel@redhat.com wrote:
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 dkliban@redhat.com 12 months ago
- Status changed from ASSIGNED to POST
- Assignee set to dkliban@redhat.com
https://github.com/pulp/pulp/pull/3736
@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.
#6
Updated by dkliban@redhat.com 12 months ago
- Status changed from POST to MODIFIED
Applied in changeset pulp|2fa951fbc7f9bce058d815aec8dbcda72b2cbbaa.
#7
Updated by daviddavis 6 months ago
- Sprint/Milestone set to 3.0
Please register to edit this issue
.