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

[jenkins-infra-bot]

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

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  strangelookingnerd any chance you could look at this one?
  

strangelookingnerd any chance you could look at this one?

[jenkins-infra-bot]

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.

[jenkins-infra-bot]

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)

[jenkins-infra-bot]

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,
)

[jenkins-infra-bot]

strangelookingnerd:

• Original comment link
• Raw content of original comment:

  I created a reproducer in Reproducer test for JENKINS-76353 #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 
  

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

[jenkins-infra-bot]

l3ender:

• Original comment link
• Raw content of original comment:

  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!
  

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!

[jenkins-infra-bot]

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.