stevens-silva opened a new issue, #8507: URL: https://github.com/apache/hop/issues/8507
Apache Hop version? 2.19.0 Java version? OpenJDK 21.0.12 Operating system Windows (also affects AlmaLinux production, same behavior) What happened? After upgrading from Hop 2.17 (Java 17) to 2.19 (Java 21), a REST Client transform calling a third-party API (Omie ERP, https://app.omie.com.br/api/v1/geral/clientes/, POST with JSON body) started failing with HTTP 500. The same pipeline worked without changes on 2.17/Java 17. The response body is a generic gateway-style fault, not the API's normal JSON error format: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope";><env:Body><env:Fault><env:Code><env:Value>env:Sender</env:Value></env:Code><env:Reason><env:Text>Bad Request</env:Text></env:Reason></env:Fault></env:Body></env:Envelope> I methodically ruled out every application-layer difference between the Hop request and a working Postman/curl request, using the Detailed log level's new "Request sent" block (very useful, thank you for that feature) to see exactly what Hop sent: Request body: byte-for-byte identical JSON to the one that works in Postman Content-Type: tested both application/json and application/json; charset=UTF-8 — no change Accept: tested both application/json and */* — no change User-Agent: tested overriding the default Apache-HttpClient/5.6.4 (Java/21.0.12) to Mozilla/5.0 — no change Tested via a REST Connection metadata object instead of a hardcoded URL (including toggling "Ignore SSL certificate check") — same 500, same body A different REST Client transform in the same pipeline, hitting a different third-party API, works normally — so this isn't a blanket regression of the transform, TLS stack, or network path The exact same request, run via curl from the same machine, same network, same credentials, succeeds with 200 OK Given all of the above, the difference is not visible at the HTTP request-line/header/body level and is most likely something at the TLS layer (ClientHello/cipher suite/ALPN — i.e. a "TLS fingerprint") that changed with the Apache HttpClient5 + Java 21 combination introduced in 2.19, which the target API's gateway is treating as anomalous and rejecting before it reaches the application layer. Steps to reproduce Set up a REST Client transform: POST, Application type: JSON, Body field pointing to a valid JSON payload, hitting an endpoint sitting behind a strict API gateway/WAF (Omie's API in this case) Run on Hop 2.19 with Java 21 → HTTP 500 gateway fault Send the identical request via curl from the same machine → HTTP 200 (If possible) Run the same pipeline on Hop 2.17 with Java 17 → works Additional context This may be related to the REST client work done for 2.19 (Rest client improvements) and/or the httpclient5 version bump in plugins/misc/rest. Happy to provide the full Detailed log (headers/body sanitized) or a minimal reproducible pipeline if useful. Issue Priority Priority: 2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
