Skip to content

[Interoperability] Declare UTF-8 for synchronous ETL text responses #235

Description

@seonghobae

Buyer-visible interoperability gap

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:

  1. 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.
  2. Observe hosted RED at the real MVC response boundary; setup/import/dependency failure is not valid RED.
  3. Change only the successful response content type to an explicit UTF-8 text/plain MediaType.
  4. Preserve failure application/problem+json, idempotency headers, response body format, authentication, ETL semantics and connector catalog.
  5. 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;
  • do not fold direct ETL authentication issue [Product/Security Gap] Replace direct ETL HTTP Basic trust boundary #161 into this response-encoding repair.

Acceptance

  • test-first hosted RED proves the protected response lacks the required UTF-8 charset;
  • exact GREEN emits text/plain;charset=UTF-8 and preserves non-ASCII success text;
  • existing ASCII/keyed/failure/catalog tests remain green;
  • machine-readable contract feat(api): add machine-readable HTTP and CDC contracts #157 is reconciled later if its media type detail requires an explicit charset expression, without calling active PR behavior shipped;
  • 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: dependenciesDependency or lockfile maintenancearea: securitySecurity boundary, hardening, or vulnerability preventionmaintenancepriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: featureNew or expanded product capability

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions