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.