uhttp: recognize application/soap+xml (SOAP 1.2) as XML content type

[cvkramer]

Summary

Recognize application/soap+xml (SOAP 1.2, RFC 3902) as an XML content type in pkg/uhttp, so WithGenericResponse auto-routes SOAP 1.2 responses to the XML parser. Also harden IsXMLContentType to match the base media type exactly (splitting off ; parameters) instead of strings.HasPrefix — this tolerates parameters like ; charset=utf-8; action=... and fixes a pre-existing bug where lookalikes such as application/soap+xmlrpc were misclassified as XML.

Changes

• pkg/uhttp/contenttype.go: add application/soap+xml; exact base-type comparison.

Tests

• pkg/uhttp/contenttype_test.go: positive (soap+xml, with charset/action params, text/xml, application/xml), negative (empty, text/html, text/plain, application/json), and lookalike-boundary cases.
• go test ./pkg/uhttp/... and go build ./... pass.

Validation

Exercised end-to-end against a live SOAP 1.2 server (application/soap+xml): responses parsed and synced by baton-http.

Part of CXH-2134. Resolves CXH-2135.

[linear-code]

CXH-2135

CXH-2134

[github-actions]

General PR Review: uhttp: recognize application/soap+xml (SOAP 1.2) as XML content type

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 1e06515304d7.
Review mode: full
View review run

Review Summary

Full PR diff scanned for security and correctness. This change adds application/soap+xml to the XML content-type set in pkg/uhttp/contenttype.go and replaces the strings.HasPrefix match in IsXMLContentType with an exact base-media-type comparison (splitting off ; parameters). The change is a net correctness improvement -- it now tolerates parameters like ; charset=utf-8; action=... while rejecting prefix lookalikes such as application/soap+xmlrpc -- and is well covered by new table-driven positive, negative, and boundary tests. No security or blocking correctness issues found.

Risk Triage

• Silence: No -- a misrouted SOAP/XML body surfaces as a parse error, not a silent wrong result. (low)
• Durability: No -- no serialized state, sync tokens, or proto/wire types touched. (low)
• Uncontrolled dimensions: No -- pure string logic, no scheduling/scale/version-pair dependence. (low)
• Consumer distance: Public SDK helper used by connectors, but the change is additive plus a strict bug fix. (low)
• Verdict: LOW. No cost-contract paths (grant expansion, compaction, checkpoint loop, open-time migration) are touched.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• pkg/uhttp/contenttype.go:31 -- The HasPrefix to exact-match change intentionally narrows detection: values that previously matched via prefix but are distinct media types (e.g. application/xml-dtd, text/xml-external-parsed-entity) now return false. This is almost certainly the desired fix, but since IsXMLContentType is an exported SDK helper, worth confirming no downstream connector relies on the broader prefix behavior. (low confidence)

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In pkg/uhttp/contenttype.go:
- Around line 31: The switch from strings.HasPrefix to an exact base-media-type
  comparison narrows IsXMLContentType so that values previously matched by prefix
  (e.g. application/xml-dtd, text/xml-external-parsed-entity) now return false.
  This is likely intended, but IsXMLContentType is an exported SDK helper. Confirm
  no downstream connector depends on the broader prefix match; if such variants must
  still be treated as XML, add them explicitly to the xmlContentTypes list rather
  than reverting to prefix matching.

[github-actions]

No blocking issues found.