You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Protected develop@622e5e6c3d534f230c390f10e3832efadfc01825 returns the successful synchronous ETL representation as ResponseEntity<String> with explicit MediaType.TEXT_PLAIN but no charset parameter. Record identifiers may contain non-ASCII Unicode by the current ETL validation contract, so a successful body such as Processed: 레코드_α is not self-describing at the HTTP media-type boundary.
RFC 6657 leaves the historical default for text/plain without a charset as US-ASCII and recommends senders provide charset information rather than make recipients guess. Spring's MediaType API supports an explicit charset parameter. The product should therefore declare the UTF-8 representation it actually produces instead of relying on framework/client defaults.
RCA
Immediate cause:EtlController.processData(...) uses .contentType(MediaType.TEXT_PLAIN) while the body is a Java String that may contain Unicode.
Technical root cause: the success representation contract specifies media type but not character encoding.
Control failure: current controller tests use ASCII-only record IDs and only assert contentTypeCompatibleWith(text/plain), so they cannot detect an ambiguous/non-UTF-8 response contract.
Impact: clients that honor the registered/default text/plain charset semantics or choose a different local default can decode valid non-ASCII result identifiers incorrectly. This is an interoperability/evidence defect, not a request-processing defect.
Smallest bounded remediation
Use strict RED -> GREEN from exact protected develop:
Add a focused controller test first that returns a real non-ASCII result string and requires exact successful Content-Type: text/plain;charset=UTF-8 plus byte/string preservation.
Observe hosted RED at the real MVC response boundary; setup/import/dependency failure is not valid RED.
Change only the successful response content type to an explicit UTF-8 text/plainMediaType.
Preserve failure application/problem+json, idempotency headers, response body format, authentication, ETL semantics and connector catalog.
Run focused/full hosted tests and current dependency/SBOM/SAST/security checks.
Non-goals
do not replace the existing newline-delimited plain-text success representation in this slice;
do not change OpenAPI paths or status codes before the runtime change is proven;
do not normalize/transliterate Unicode identifiers;
do not alter request JSON encoding or database persistence;
literal-source evidence, non-vacuous coverage, scanner completeness and independent review remain separate merge gates.
Primary reference — APA 7
Melnikov, A., & Reschke, J. (2012). Update to MIME regarding "charset" parameter handling in textual media types (RFC 6657). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc6657
Buyer-visible interoperability gap
Protected
develop@622e5e6c3d534f230c390f10e3832efadfc01825returns the successful synchronous ETL representation asResponseEntity<String>with explicitMediaType.TEXT_PLAINbut nocharsetparameter. Record identifiers may contain non-ASCII Unicode by the current ETL validation contract, so a successful body such asProcessed: 레코드_αis not self-describing at the HTTP media-type boundary.RFC 6657 leaves the historical default for
text/plainwithout a charset as US-ASCII and recommends senders provide charset information rather than make recipients guess. Spring'sMediaTypeAPI supports an explicit charset parameter. The product should therefore declare the UTF-8 representation it actually produces instead of relying on framework/client defaults.RCA
EtlController.processData(...)uses.contentType(MediaType.TEXT_PLAIN)while the body is a JavaStringthat may contain Unicode.contentTypeCompatibleWith(text/plain), so they cannot detect an ambiguous/non-UTF-8 response contract.text/plaincharset semantics or choose a different local default can decode valid non-ASCII result identifiers incorrectly. This is an interoperability/evidence defect, not a request-processing defect.Smallest bounded remediation
Use strict RED -> GREEN from exact protected develop:
Content-Type: text/plain;charset=UTF-8plus byte/string preservation.text/plainMediaType.application/problem+json, idempotency headers, response body format, authentication, ETL semantics and connector catalog.Non-goals
Acceptance
text/plain;charset=UTF-8and preserves non-ASCII success text;Primary reference — APA 7
Melnikov, A., & Reschke, J. (2012). Update to MIME regarding "charset" parameter handling in textual media types (RFC 6657). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc6657