Allow opting out of the default charset being appended to the request `Content-Type` header

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#1,729 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
72/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
api, backend

Rechercherichtung

Beginne mit AwsProxyHttpServletRequestReader.java und ContainerConfig.java, um nachzuverfolgen, wie der Standardzeichensatz hinzugefügt und konfiguriert wird. Lies oder führe anschließend AwsProxyHttpServletRequestReaderTest aus; ergänze Tests für das Deaktivieren, das unveränderte Standardverhalten und einen vorhandenen charset=-Parameter. Als erledigt gilt die Aufgabe, wenn das Deaktivieren den eingehenden Content-Type unverändert lässt und das Standardverhalten intakt bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

  • Framework version: 3.0.2 (also confirmed identical in 3.0.3 and on main)
  • Implementations: All (core AwsProxyHttpServletRequestReader)

Scenario

AwsProxyHttpServletRequestReader.readRequest(...) rewrites the incoming Content-Type header on the
proxy event before the servlet request is built (and so before any filter runs):

// AwsProxyHttpServletRequestReader.java#L55
request.getMultiValueHeaders().putSingle(HttpHeaders.CONTENT_TYPE, getContentTypeWithCharset(contentType, config));

If the client sent a Content-Type without a charset parameter, getContentTypeWithCharset appends
"; charset=" + config.getDefaultContentCharset(), which defaults to ISO-8859-1:

This breaks any application that has to see the request headers exactly as the client sent them.
The case I hit is request-signature verification: the client signs a set of request components that
includes Content-Type (e.g. an HTTP message signature, a proof-of-possession token whose claims
hash the request headers, or an HMAC scheme). A servlet filter then recomputes the signature input
from HttpServletRequest. Because the container has already changed application/json to
application/json; charset=ISO-8859-1, the recomputed hash never matches and every request that
omits a charset fails verification.

There is currently no way to turn this off through ContainerConfig:

  • setDefaultContentCharset(null) produces Content-Type: application/json; charset=null
  • setDefaultContentCharset("") produces Content-Type: application/json; charset=

Both still change the header. The only workarounds are to replace or subclass the request reader, or to
reverse-engineer the exact appended suffix inside the verifier and retry with it stripped. Both
depend on container internals.

(Related background: #175 covered how a forced default charset interacts badly with
application/json, which RFC 8259 defines as UTF-8 and which has no charset parameter.)

Expected behavior

There should be a supported way to make the container leave the client's Content-Type unmodified.
The default behavior can stay as it is.

Actual behavior

Whenever no charset is present, the header is always rewritten, and no configuration value avoids it.

Steps to reproduce

  1. Build an AwsProxyRequest with header Content-Type: application/json (no charset).
  2. Run it through AwsProxyHttpServletRequestReader.readRequest(...). Calling
    setDefaultContentCharset(null) on the ContainerConfig first doesn't change the outcome.
  3. Observe servletRequest.getHeader("Content-Type") returns application/json; charset=ISO-8859-1
    (or ; charset=null), and that the original event's multi-value headers were mutated as well.

Proposed fix

Make the append opt-out-able, default unchanged. Two options, happy to go with whichever the
maintainers prefer:

Option A: treat a null/blank charset as "don't append" (smallest diff, no new API)

private String getContentTypeWithCharset(String headerValue, ContainerConfig config) {
    if (headerValue == null || "".equals(headerValue.trim())) {
        return headerValue;
    }
    if (headerValue.contains("charset=")) {
        return headerValue;
    }
    String charset = config.getDefaultContentCharset();
    if (charset == null || charset.trim().isEmpty()) {
        return headerValue;
    }
    ...
}

Users opt out with config.setDefaultContentCharset(null). Downside: it gives null a special meaning
that isn't obvious from the API, so the setDefaultContentCharset Javadoc would need to document it.
Right now null just produces a malformed charset=null value, so nobody can depend on the current
behavior.

Option B: explicit boolean flag (more readable intent)

Add ContainerConfig#setAppendDefaultContentCharset(boolean) (default true) and check it in
getContentTypeWithCharset. It's a slightly bigger change (field, getter/setter, default init, guard),
but the setting explains itself.

Either way the default (ISO-8859-1 appended) stays the same, so existing users aren't affected. I'm
happy to open a PR with the change plus tests in AwsProxyHttpServletRequestReaderTest. The tests would
cover: no suffix when opted out, the default path still appending, and an existing charset= left as is.

Vorherrschende Sprache
Java
Sterne
1.6k
Forks
575
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
12

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aws/serverless-java-container

Alle Issues in aws/serverless-java-container

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.