Issue #4061: DownloadResult does not contain the headers sent with the artifact - Pulp

Actions

Send by e-mail Copy link

Issue #4061

closed

DownloadResult does not contain the headers sent with the artifact

Added by dkliban@redhat.com about 6 years ago. Updated almost 5 years ago.

Status:

CLOSED - CURRENTRELEASE

Priority:

Normal

Assignee:

dkliban@redhat.com

Category:

Sprint/Milestone:

3.0.0

Start date:

Due date:

Estimated time:

Severity:

2. Medium

Version:

Platform Release:

OS:

Triaged:

Yes

Groomed:

Sprint Candidate:

Tags:

Sprint:

Sprint 44

Quarter:

Description

The DownloadResult[0] 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.

[0] https://docs.pulpproject.org/en/3.0/nightly/plugins/plugin-api/download.html#pulpcore.plugin.download.DownloadResult

Actions

Copy link

Updated by CodeHeeler about 6 years ago

Triaged changed from No to Yes
Sprint set to Sprint 44

Actions

Copy link

Updated by jortel@redhat.com about 6 years 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.

Actions

Copy link

Updated by dkliban@redhat.com about 6 years ago

Status changed from NEW to ASSIGNED

Actions

Copy link

Updated by bmbouter about 6 years 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.

Actions

Copy link

Updated by dkliban@redhat.com about 6 years 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.