Defect attachments timeout through corporate proxy in environment setup

ALM IBM Engineering Lifecycle Management
, , , , , , , ,
1

We’re running ELM 7.0.1 behind a corporate proxy and encountering consistent timeouts when users try to upload attachments to defects. Screenshots, log files, anything over 2MB fails with a proxy timeout error after exactly 30 seconds.

Error in browser console:


POST /ccm/service/com.ibm.team.workitem.common.internal.rest.IAttachmentRestService/attachment
Status: 504 Gateway Timeout
Proxy-Connection: keep-alive
Timeout: 30000ms

Smaller attachments (under 1MB) upload successfully, which suggests the proxy is killing connections that take too long. Our network team says the proxy timeout is set to 60 seconds, but we’re hitting timeouts at 30 seconds, so something in the ELM Liberty server configuration might be interfering.

SSL certificates are properly configured in the Liberty truststore - we can access the ELM web UI and create defects without issues. It’s only the attachment upload that fails. Has anyone dealt with proxy timeout tuning for large file uploads in ELM?

2

Karen, good call on the SSL inspection. Our proxy does perform SSL termination and re-encryption. I checked the Liberty truststore and we only have the root CA, not the intermediate certificates from the proxy. That could explain why uploads fail midstream - the SSL session is probably getting renegotiated during the upload and failing validation.

3

Here’s the complete solution for handling attachment uploads through a corporate proxy:

Step 1: Increase Liberty HTTP Timeout Settings Edit your Liberty server.xml (typically in server/liberty/servers/clm/server.xml) and modify the httpEndpoint configuration:

<httpEndpoint id="defaultHttpEndpoint"
              readTimeout="120s"
              writeTimeout="120s"
              connectionTimeout="60s" />

The readTimeout controls how long Liberty waits for data from the client (critical for uploads). Setting it to 120 seconds gives large attachments time to transfer through the proxy.

Step 2: Configure Proxy SSL Certificates Your corporate proxy is performing SSL inspection, so you need to import the proxy’s certificate chain into Liberty’s truststore:


keytool -import -trustcacerts -alias proxy_intermediate \
  -file proxy-intermediate.cer \
  -keystore server/liberty/servers/clm/resources/security/trust.jks

Get the intermediate certificate from your network team (the cert the proxy uses when re-encrypting traffic). Without this, SSL handshakes fail during long uploads.

Step 3: Enable Proxy Header Forwarding Add the following to your server.xml to ensure Liberty correctly handles X-Forwarded headers from the proxy:

<remoteIp proxies="10.0.0.0/8"
          useRemoteIpInAccessLog="true" />

Replace the IP range with your actual proxy server addresses. This prevents the attachment service from rejecting uploads due to IP validation issues.

Step 4: Adjust Proxy Buffer Settings Work with your network team to configure the corporate proxy to NOT buffer entire uploads before forwarding to Liberty. For large files, buffering causes the client connection to timeout while the proxy holds the data. The proxy should stream the upload directly to the backend Liberty server.

For Nginx proxies, this means setting:


proxy_request_buffering off;
proxy_buffering off;

For Apache proxies, use:


SetEnv proxy-sendcl 1

Step 5: Configure Client Upload Timeout On the ELM web client side, increase the attachment upload timeout in the CCM application settings. Go to Server Administration → Advanced Properties and add:


com.ibm.team.workitem.service.attachment.upload.timeout=180000

This gives the browser 3 minutes to complete the upload before the client-side JavaScript times out.

Step 6: Verify SSL Certificate Chain Run this command from your ELM server to verify the full certificate chain is valid through the proxy:


openssl s_client -connect your-elm-server.com:443 -showcerts

You should see the complete chain including the proxy’s intermediate certificate. If verification fails, you’re missing a cert in the truststore.

Step 7: Test Upload Performance After making these changes, restart the Liberty server and test uploading a 5MB attachment to a defect. Monitor the ccm.log for any SSL handshake errors or timeout messages. The upload should complete successfully within the new 120-second timeout window.

Additional Proxy Timeout Tuning: If you still see 504 errors after these changes, the corporate proxy itself might have a hard timeout limit. Have your network team check the proxy’s backend connection timeout (not the client-facing timeout). For Squid proxies, this is the read_timeout directive. It should be set to at least 180 seconds to handle large attachments.

After implementing all steps, your team should be able to upload screenshots and log files to defects without hitting proxy timeouts, even for files over 10MB.

4

You need both timeout adjustments AND proper proxy configuration. For inbound attachment uploads through a reverse proxy, the Liberty server doesn’t need proxy settings - those are only for outbound connections. However, you do need to ensure the proxy headers are being forwarded correctly.

Add the RemoteIpValve configuration to your server.xml so Liberty trusts the X-Forwarded-For headers from your proxy. Without this, the attachment service might reject uploads thinking they’re coming from an untrusted source. Also check if your proxy is buffering the entire upload before forwarding to Liberty - that can cause timeouts on large files.

5

The 30-second timeout is likely coming from the Liberty HTTP endpoint configuration, not the corporate proxy. Check your server.xml for the httpEndpoint element and look for connectionTimeout or readTimeout settings. Default is usually 30 seconds, which matches what you’re seeing.

You’ll need to increase those timeout values to handle larger file uploads through the proxy.

6

Don’t overlook SSL certificate chain validation. If your corporate proxy is doing SSL inspection (man-in-the-middle), the Liberty truststore needs the proxy’s intermediate certificates, not just the root CA. Attachment uploads might be failing SSL handshake partway through the transfer, which manifests as a timeout.

Run openssl s_client against your ELM server from inside the network and verify the full certificate chain is valid. If you see any verification errors, that’s your issue.