Project

Profile

Help

Send by e-mail

Issue #4061

DownloadResult does not contain the headers sent with the artifact

Added by dkliban@redhat.com over 2 years ago. Updated about 1 year 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:
No
Sprint Candidate:
No
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

Associated revisions

Revision 2fa951fb View on GitHub
Added by dkliban@redhat.com about 2 years 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 about 2 years 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 over 2 years ago

  • Triaged changed from No to Yes
  • Sprint set to Sprint 44

#2 Updated by jortel@redhat.com over 2 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.

#3 Updated by dkliban@redhat.com about 2 years ago

  • Status changed from NEW to ASSIGNED

#4 Updated by bmbouter about 2 years 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 about 2 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.

#6 Updated by dkliban@redhat.com about 2 years ago

  • Status changed from POST to MODIFIED

#7 Updated by daviddavis almost 2 years ago

  • Sprint/Milestone set to 3.0.0

#8 Updated by bmbouter over 1 year ago

  • Tags deleted (Pulp 3)

#9 Updated by bmbouter about 1 year ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Please register to edit this issue

Send by e-mail

Also available in: Atom PDF