Project

Profile

Help

Issue #4061

DownloadResult does not contain the headers sent with the artifact

Added by dkliban@redhat.com about 1 year ago. Updated 6 months ago.

Status:
MODIFIED
Priority:
Normal
Category:
-
Sprint/Milestone:
Start date:
Due date:
Severity:
2. Medium
Version:
Platform Release:
Blocks Release:
OS:
Backwards Incompatible:
No
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 44

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.

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

Associated revisions

Revision 2fa951fb View on GitHub
Added by dkliban@redhat.com 12 months ago

Problem: DownloadResult is missing response headers

Solution: Add response header to the DownloadResult

The HttpDownloader now adds the response headers to the DownloadResult.

closes #4061
https://pulp.plan.io/issues/4061

Revision 2fa951fb View on GitHub
Added by dkliban@redhat.com 12 months ago

Problem: DownloadResult is missing response headers

Solution: Add response header to the DownloadResult

The HttpDownloader now adds the response headers to the DownloadResult.

closes #4061
https://pulp.plan.io/issues/4061

Revision 2fa951fb View on GitHub
Added by dkliban@redhat.com 12 months ago

Problem: DownloadResult is missing response headers

Solution: Add response header to the DownloadResult

The HttpDownloader now adds the response headers to the DownloadResult.

closes #4061
https://pulp.plan.io/issues/4061

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

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

#7 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#8 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF