Skip to content

[JENKINS-76353] Request fails if response contains header Content-Encoding: none #336

New issue
New issue
Open
Bug
#347
Open
[JENKINS-76353] Request fails if response contains header Content-Encoding: none#336
Bug
#347
Labels
bugcomponent:http-request-pluginimported-jira-issuepriority:minorresolution:unresolved

Description

@jenkins-infra-bot
jenkins-infra-bot
opened on Jan 12, 2026

We recently updated the HTTP request plugin to version 1.24 and are seeing issues in one workflow where a vendor API returns the response header Content-Encoding: none.

This results in the plugin throwing the following exception:

org.apache.hc.core5.http.HttpException: Unsupported Content-Encoding: none
	at org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:153)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:185)
Caused: org.apache.hc.client5.http.ClientProtocolException: Unsupported Content-Encoding: none
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:188)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
	at org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
	at jenkins.plugins.http_request.util.HttpClientUtil.execute(HttpClientUtil.java:122)
	at jenkins.plugins.http_request.HttpRequestExecution.executeRequest(HttpRequestExecution.java:484)
	at jenkins.plugins.http_request.HttpRequestExecution.authAndRequest(HttpRequestExecution.java:385)
	at jenkins.plugins.http_request.HttpRequestExecution.call(HttpRequestExecution.java:293)

I'm guessing this was due to the migration to httpclient 5 in version 1.21.

The plugin appears to have gracefully handled (ignored) the API request in the previous version.

Is there a way to configure the plugin to ignore this type of response? Thank you! m

Originally reported by l3ender, imported from: Request fails if response contains header Content-Encoding: none
  • assignee: janario
  • status: Open
  • priority: Minor
  • component(s): http-request-plugin
  • resolution: Unresolved
  • votes: 0
  • watchers: 3
  • imported: 20260702-081740
Raw content of original issue 
We recently updated the HTTP request plugin to version 1.24 and are seeing issues in one workflow where a vendor API returns the response header Content-Encoding: none.



This results in the plugin throwing the following exception:




org.apache.hc.core5.http.HttpException: Unsupported Content-Encoding: none
	at org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:153)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:110)
	at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:185)
Caused: org.apache.hc.client5.http.ClientProtocolException: Unsupported Content-Encoding: none
	at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:188)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:87)
	at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:55)
	at org.apache.hc.client5.http.classic.HttpClient.executeOpen(HttpClient.java:183)
	at jenkins.plugins.http_request.util.HttpClientUtil.execute(HttpClientUtil.java:122)
	at jenkins.plugins.http_request.HttpRequestExecution.executeRequest(HttpRequestExecution.java:484)
	at jenkins.plugins.http_request.HttpRequestExecution.authAndRequest(HttpRequestExecution.java:385)
	at jenkins.plugins.http_request.HttpRequestExecution.call(HttpRequestExecution.java:293)




I'm guessing this was due to the migration to httpclient 5 in version 1.21.


The plugin appears to have gracefully handled (ignored) the API request in the previous version.


Is there a way to configure the plugin to ignore this type of response? Thank you! m

Activity

  1. jenkins-infra-bot commented on Jan 13, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jan 13, 2026
    Author
    markewaite:

    strangelookingnerd any chance you could look at this one?

  2. jenkins-infra-bot commented on Jan 19, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jan 19, 2026
    Author
    strangelookingnerd:
    • Original comment link
    • Raw content of original comment: 
      Hey l3ender,
      


      I took a look at the httpclient implementation and could not really see a change in behavior compared to 4.5.x. From what I can tell "unknown" values for Content-Encoding should be ignored in both versions by default.
      


      I also tried to reproduce the issue but am unable to do so. I suspect that there might be other headers in the response that trip the logic.
      


      Would you be able to give me more details on the request and also the response? I don't mind the contents being redacted if needed, but I require a reproducer to find the root cause.

    Hey l3ender,

    I took a look at the httpclient implementation and could not really see a change in behavior compared to 4.5.x. From what I can tell "unknown" values for Content-Encoding should be ignored in both versions by default.

    I also tried to reproduce the issue but am unable to do so. I suspect that there might be other headers in the response that trip the logic.

    Would you be able to give me more details on the request and also the response? I don't mind the contents being redacted if needed, but I require a reproducer to find the root cause.

  3. jenkins-infra-bot commented on Jan 23, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jan 23, 2026
    Author
    l3ender:
    • Original comment link
    • Raw content of original comment: 
      Sorry for the delay, strangelookingnerd.
      


      The request is to a vendor API to download a file. Here's a curl command for the API in question--hope that helps!
      


      

      -> curl -v -H "Authorization: Api-Token $DYNATRACE_API_TOKEN" "https://yjz43250.live.dynatrace.com/api/v1/deployment/installer/agent/unix/paas-sh/latest?flavor=musl&include=dotnet"
* Host yjz43250.live.dynatrace.com:443 was resolved.
* IPv6: (none)
* IPv4: 3.233.203.93, 44.219.156.205, 18.209.64.226, 18.235.100.163, 34.193.16.111, 18.233.41.114, 18.232.217.30, 184.73.25.73, 35.171.91.193, 98.95.102.77, 107.22.119.249, 3.213.173.163
*   Trying 3.233.203.93:443...
* Connected to yjz43250.live.dynatrace.com (3.233.203.93) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: C=US; ST=Massachusetts; L=Waltham; O=Dynatrace LLC; CN=*.live.dynatrace.com
*  start date: Nov 13 00:00:00 2025 GMT
*  expire date: Dec 14 23:59:59 2026 GMT
*  subjectAltName: host "yjz43250.live.dynatrace.com" matched cert's "*.live.dynatrace.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET /api/v1/deployment/installer/agent/unix/paas-sh/latest?flavor=musl&include=dotnet HTTP/1.1
> Host: yjz43250.live.dynatrace.com
> User-Agent: curl/8.5.0
> Accept: */*
> Authorization: Api-Token xxx
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< date: Fri, 23 Jan 2026 15:30:38 GMT
< vary: Accept-Encoding
< content-disposition: attachment; filename="paasInstaller_Unix_all.sh"; size=55191181
< etag: "a21bcba577f439d703fbe1561f77213bedf7a019616fae65d9a76d2b3687773b"
< content-encoding: none
< content-type: application/octet-stream
< cache-control: no-store, no-cache
< pragma: no-cache
< x-robots-tag: noindex
< dynatrace-response-source: Cluster
< server: ruxit server
< content-length: 55191181
< strict-transport-security: max-age=31536000;includeSubDomains
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection
* TLSv1.3 (OUT), TLS alert, close notify (256)

    Sorry for the delay, strangelookingnerd.

    The request is to a vendor API to download a file. Here's a curl command for the API in question--hope that helps!

    -> curl -v -H "Authorization: Api-Token $DYNATRACE_API_TOKEN" "https://yjz43250.live.dynatrace.com/api/v1/deployment/installer/agent/unix/paas-sh/latest?flavor=musl&include=dotnet"
* Host yjz43250.live.dynatrace.com:443 was resolved.
* IPv6: (none)
* IPv4: 3.233.203.93, 44.219.156.205, 18.209.64.226, 18.235.100.163, 34.193.16.111, 18.233.41.114, 18.232.217.30, 184.73.25.73, 35.171.91.193, 98.95.102.77, 107.22.119.249, 3.213.173.163
*   Trying 3.233.203.93:443...
* Connected to yjz43250.live.dynatrace.com (3.233.203.93) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: C=US; ST=Massachusetts; L=Waltham; O=Dynatrace LLC; CN=*.live.dynatrace.com
*  start date: Nov 13 00:00:00 2025 GMT
*  expire date: Dec 14 23:59:59 2026 GMT
*  subjectAltName: host "yjz43250.live.dynatrace.com" matched cert's "*.live.dynatrace.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> GET /api/v1/deployment/installer/agent/unix/paas-sh/latest?flavor=musl&include=dotnet HTTP/1.1
> Host: yjz43250.live.dynatrace.com
> User-Agent: curl/8.5.0
> Accept: */*
> Authorization: Api-Token xxx
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< date: Fri, 23 Jan 2026 15:30:38 GMT
< vary: Accept-Encoding
< content-disposition: attachment; filename="paasInstaller_Unix_all.sh"; size=55191181
< etag: "a21bcba577f439d703fbe1561f77213bedf7a019616fae65d9a76d2b3687773b"
< content-encoding: none
< content-type: application/octet-stream
< cache-control: no-store, no-cache
< pragma: no-cache
< x-robots-tag: noindex
< dynatrace-response-source: Cluster
< server: ruxit server
< content-length: 55191181
< strict-transport-security: max-age=31536000;includeSubDomains
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: " to save to a file.
* Failure writing output to destination
* Closing connection
* TLSv1.3 (OUT), TLS alert, close notify (256)

  4. jenkins-infra-bot commented on Jan 23, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jan 23, 2026
    Author
    l3ender:
    • Original comment link
    • Raw content of original comment: 
      If it's helpful, here's our usage of the jenkins plugin in our pipeline:
      


      

      httpRequest(
    url: "https://yjz43250.live.dynatrace.com/api/v1/deployment/installer/agent/unix/paas-sh/latest?flavor=${flavor}${includeQueryString}",
    customHeaders: [[name: 'Authorization', value: 'Api-Token ' + env.DT_API_TOKEN, maskValue: true]],
    outputFile: filepath,
)

    If it's helpful, here's our usage of the jenkins plugin in our pipeline:

    httpRequest(
    url: "https://yjz43250.live.dynatrace.com/api/v1/deployment/installer/agent/unix/paas-sh/latest?flavor=${flavor}${includeQueryString}",
    customHeaders: [[name: 'Authorization', value: 'Api-Token ' + env.DT_API_TOKEN, maskValue: true]],
    outputFile: filepath,
)

  5. jenkins-infra-bot commented on Jan 23, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jan 23, 2026
    Author
    strangelookingnerd:

    I created a reproducer in #232

    Unfortunately I'm unable to reproduce the error you are seeing. Also looking at the code in httpclient5 does not really give me any ideas how this exception can be thrown as the default behavior is to ignore unknown values for Content-Encoding. See https://github.com/apache/httpcomponents-client/blob/5.5.x/httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/ContentCompressionExec.java#L173-L196 

    Not sure how to continue here

  6. jenkins-infra-bot commented on Jan 27, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jan 27, 2026
    Author
    l3ender:

    I see the version of Apache HttpComponents Client 5.x API that is installed in our Jenkins is 5.6-183.ve5a_8a_b_e71e59. This is using version 5.6 of org.apache.httpcomponents.client5:httpclient5.

    Based on that, I see different code in ContentCompressionExec than what you linked for version 5.5 - https://github.com/apache/httpcomponents-client/blob/rel/v5.6/httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/ContentCompressionExec.java#L143-L156.

    Please let me know if that helps or if I can provide any other info from our environment--thanks!

  7. jenkins-infra-bot commented on Feb 4, 2026

    @jenkins-infra-bot
    jenkins-infra-bot
    on Feb 4, 2026
    Author
    strangelookingnerd:
    • Original comment link
    • Raw content of original comment: 
      You are absolutely right, thanks for double checking!
      


      This change in behavior was introduced in Unsupported content encoding to be treated as an error apache/httpcomponents-client#698 and was shipped in the latest 5.6 release. While I don’t agree with the reasoning in there, it’s not my decision to make either. Further I do not think that there is much we can do in the plugin as of now. The workaround mentioned in the PR could be implemented in the plugin, I would need to look into that. Other than that you could try alternatives to the plugin, such as curl or wget. 

    You are absolutely right, thanks for double checking!

    This change in behavior was introduced in apache/httpcomponents-client#698 and was shipped in the latest 5.6 release. While I don’t agree with the reasoning in there, it’s not my decision to make either. Further I do not think that there is much we can do in the plugin as of now. The workaround mentioned in the PR could be implemented in the plugin, I would need to look into that. Other than that you could try alternatives to the plugin, such as curl or wget. 

  8. jenkins-infra-bot
    added
    bug
    imported-jira-issue
    component:http-request-plugin
    priority:minor
    resolution:unresolved
    on Jul 2, 2026
  9. jenkins-infra-bot
    added the
    Bug
    issue type on Jul 2, 2026
  10. jenkins-infra-bot
    removed
    bug
    on Jul 2, 2026
  11. h3nr1-d14z
    added
    bug
    on Sep 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugcomponent:http-request-pluginimported-jira-issuepriority:minorresolution:unresolved

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions