ARTIFACTORY: Resolving 502 errors and connection resets responses when expecting 401/403

ARTIFACTORY: Resolving 502 errors and connection resets responses when expecting 401/403

AuthorFullName__c
Daniel Milman
articleNumber
000006308
ft:sourceType
Salesforce
FirstPublishedDate
2024-12-31T12:27:32Z
lastModifiedDate
2024-12-31
VersionNumber
1
Introduction

When a user attempts to upload or overwrite an artifact in Artifactory without the necessary permissions, the underlying Tomcat server may generate an “HTTP/1.1 100 Continue” response followed by either a “401 Unauthorized” or a “403 Forbidden” status. For example, executing a command such as:
curl -utest:pass -T artifact.tar "http://IP/artifactory/example-repo-local/artifact.tar" -vvv

* Server auth using Basic with user 'test'
> PUT /artifactory/example-repo-local/artifact.tar HTTP/1.1
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
<
< HTTP/1.1 403 Forbidden
{
  "errors" : [ {
    "status" : 403,
    "message" : "Not enough permissions to delete/overwrite artifact 'example-repo-local:artifact.tar' (user: test needs DELETE permission)."
  } ]
* Recv failure: Connection reset by peer
* Closing connection
curl: (56) Recv failure: Connection reset by peer
}%

This behavior can lead to issues with certain applications and tools, such as F5 and Apache httpd reverse proxy, which may not handle the “HTTP/1.1 100 continue” response correctly. This can result in connection reset or “502 bad gateway” errors, disrupting build pipelines and impacting workflows. This issue with another workflow is also described here: https://jfrog.atlassian.net/browse/RTFACT-22904


Explanation of the HTTP/1.1 100 continue



The “HTTP/1.1 100 continue” status code is part of the HTTP/1.1 protocol. It indicates to the client that the server has received the initial part of the request's headers and is ready to accept the body of the request. This response is typically sent to allow the client to avoid sending a large request body if the server will reject the request based on the headers alone.


In our case, the initial “100 response” comes from Tomcat, the underlying web server, before the request reaches Artifactory. For example, if a user tries to overwrite an artifact without the appropriate DELETE permission, Tomcat sends a “100 continue” response to the client while Artifactory internally determines that the operation should be rejected with a “403 Forbidden” due to insufficient permissions.


If an application or intermediary tool (such as F5 or Apache) is not equipped to handle the “100 continue” response correctly, it may result in unexpected response code sent back. 
For more detailed information on this status code, please refer to the official 
Apache Tomcat 10 Configuration Reference (10.1.34) - The HTTP Connector.


Solution

To address this issue and prevent the “HTTP/1.1 100 continue” response from being sent, and by extension the 502 response from the reverse proxy we can follow these steps to modify the Tomcat connector configuration:

1. Locate the system.yaml configuration file at:

/opt/jfrog/artifactory/var/etc/system.yaml

2. Edit the Configuration :
artifactory:
    tomcat:
        connector:
            extraConfig: "continueResponseTiming='onRead'"

3. Restart Artifactory to apply the configuration changes

This setting allows Tomcat to interact with the request more intelligently. With “onRead” set, Tomcat waits until the application begins reading the request body to send the “100 continue” response. This gives the Artifactory an opportunity to inspect the request headers, assess permissions, and if needed, respond to the client with an appropriate error status (like 403 Forbidden) before the client sends potentially large payloads.


Conclusion

By implementing the continueResponseTiming='onRead' property in your Tomcat configuration, you can effectively resolve unintended response codes returned from Artifactory.