• 1.8

      It seems that when you upload even a file named something.txt, it gets an octet-stream content type on S3, so even if you click the view link in Classic UI on the artifacts page, your browser gets a downloaded file rather than displaying inline. Must be some way to tell jClouds/S3 to sniff content type automatically. OTOH there may be some dangerous types which we would want to serve only as plain text or binary.

          [JENKINS-50772] Content type not set reasonably

          Jarrad Whitaker added a comment - - edited

          (this is actually a blocker for our team to use this plugin, "I can't see my test report when I click the link ")

          Jarrad Whitaker added a comment - - edited (this is actually a blocker for our team to use this plugin, "I can't see my test report when I click the link ")

          Jesse Glick added a comment -

          I doubt RobustHttpClient is involved; the content type setting would be done on the master side using the AWS SDK. I think. Will not know for sure until a fix is implemented. Perhaps dcurrie wants to take a stab at it?

          Jesse Glick added a comment - I doubt RobustHttpClient is involved; the content type setting would be done on the master side using the AWS SDK. I think. Will not know for sure until a fix is implemented. Perhaps dcurrie wants to take a stab at it?

          Jarrad Whitaker added a comment - - edited

          Jarrad Whitaker added a comment - - edited Unless I'm reading wrong, by https://github.com/jenkinsci/artifact-manager-s3-plugin/blob/master/src/main/java/io/jenkins/plugins/artifact_manager_jclouds/JCloudsArtifactManager.java#L115 and https://github.com/jenkinsci/artifact-manager-s3-plugin/blob/master/src/main/java/io/jenkins/plugins/artifact_manager_jclouds/JCloudsArtifactManager.java#L134, it works by getting a presigned S3 url and `uploadFile`ing to it with RobustHttpClient.

          David Currie added a comment -

          My reading is the same as akdor1154. The S3 API indicates that the default Content-Type on a PUT is binary/octet-stream unless you specify otherwise.

          David Currie added a comment - My reading is the same as akdor1154 . The S3 API indicates that the default Content-Type on a PUT is binary/octet-stream unless you specify otherwise.

          Jesse Glick added a comment -

          Right, the question is whether the URL itself can encode the desired content type or whether this needs to be handled as an HTTP header by the uploading code. In the latter case, RobustHttpClient.uploadFile would need to be amended to set a header.

          (Then the next question is what content type to pick. Files.probeContentType seems like the right choice.)

          Jesse Glick added a comment - Right, the question is whether the URL itself can encode the desired content type or whether this needs to be handled as an HTTP header by the uploading code. In the latter case, RobustHttpClient.uploadFile would need to be amended to set a header. (Then the next question is what content type to pick. Files.probeContentType seems like the right choice.)

          Seppo Yli-Olli added a comment - - edited

          Even if you only populated content type for most common things (txt, html), this would still be useful. Is this being actively worked on? This limitation makes using HTML reports through Jenkins web UI quite painful if this plugin is active. My assumption based on what I've seen thus far is latter option is the right one but it could be that I'm just missing some details of presigned URL's.

          Seppo Yli-Olli added a comment - - edited Even if you only populated content type for most common things (txt, html), this would still be useful. Is this being actively worked on? This limitation makes using HTML reports through Jenkins web UI quite painful if this plugin is active. My assumption based on what I've seen thus far is latter option is the right one but it could be that I'm just missing some details of presigned URL's.

          I took a stab at this, and was able to get a custom-built version of the plugin working for me locally: it uploads files to S3 with content-type set appropriately which makes them properly viewable in the browser (for inline file types such as text/plain and text/html) instead of always forcing them to be downloaded.

           

          This took changes to both the artifact-manager-s3 and apache-httpcomponents-client-4-api-plugin repositories, since I had to ensure when the plugin performs an HTTP upload it also specifies the "Content-Type" header and I used a new method signature in RobustHTTPClient to do so.

           

          My changes can be viewed at:

           

           

          While, as I said, a custom plugin that has these changes appears to do the right thing for me and I also added several tests to verify uploads to (and subsequent downloads from) S3 are setting the content-type now, this is my first contribution to the project so I might well have missed something. Any suggestions or feedback welcome... I hope it at least provides a starting point for a fix to this issue, if nothing else.

          Robin Verduijn added a comment - I took a stab at this, and was able to get a custom-built version of the plugin working for me locally: it uploads files to S3 with content-type set appropriately which makes them properly viewable in the browser (for inline file types such as text/plain and text/html) instead of always forcing them to be downloaded.   This took changes to both the artifact-manager-s3 and apache-httpcomponents-client-4-api-plugin repositories, since I had to ensure when the plugin performs an HTTP upload it also specifies the "Content-Type" header and I used a new method signature in RobustHTTPClient to do so.   My changes can be viewed at:   https://github.com/jenkinsci/apache-httpcomponents-client-4-api-plugin/pull/24 https://github.com/jenkinsci/artifact-manager-s3-plugin/pull/100   While, as I said, a custom plugin that has these changes appears to do the right thing for me and I also added several tests to verify uploads to (and subsequent downloads from) S3 are setting the content-type now, this is my first contribution to the project so I might well have missed something. Any suggestions or feedback welcome... I hope it at least provides a starting point for a fix to this issue, if nothing else.

          Jesse Glick added a comment -

          Thanks! I will try to review soon.

          Jesse Glick added a comment - Thanks! I will try to review soon.

          Oleg Nenashev added a comment - Released in  https://github.com/jenkinsci/apache-httpcomponents-client-4-api-plugin/releases/tag/apache-httpcomponents-client-4-api-4.5.10-2.0

          Jesse Glick added a comment -

          No oleg_nenashev that was just an API.

          Jesse Glick added a comment - No oleg_nenashev that was just an API.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            6 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: