What causes "%s content encoding not supported" in ory/hydra?

Change the client to send Content-Encoding: gzip (or no encoding) for requests to this endpoint

%s content encoding not supported

Error message

%s content encoding not supported

What it means

The gzip_server middleware only knows how to decode request bodies with Content-Encoding values gzip, identity, or the empty string. Any other encoding (br, deflate, zstd, etc.) is handed to the configured error handler with this error and the request never reaches the next handler with a decoded body.

Source

Thrown at oryx/httpx/gzip_server.go:45

	return &CompressionRequestReader{
		ErrHandler: eh,
	}
}

func (c *CompressionRequestReader) ServeHTTP(w http.ResponseWriter, r *http.Request, next http.HandlerFunc) {
	for _, enc := range strings.Split(r.Header.Get("Content-Encoding"), ",") {
		switch enc = strings.TrimSpace(enc); enc {
		case "gzip":
			reader, err := gzip.NewReader(r.Body)
			if err != nil {
				c.ErrHandler(w, r, err)
				return
			}
			r.Body = io.NopCloser(reader)
		case "identity", "":
			// nothing to do
		default:
			c.ErrHandler(w, r, fmt.Errorf("%s content encoding not supported", enc))
		}
	}

	next(w, r)
}

View on GitHub (pinned to 4174065ffb)

Solutions

Change the client to send Content-Encoding: gzip (or no encoding) for requests to this endpoint
Add a case for the needed encoding in the middleware (e.g. via compress/gzip-like reader for that format)
Reject unsupported encodings earlier at the gateway/proxy with a clear 415 response
Return 415 Unsupported Media Type from the ErrHandler so clients get a meaningful status instead of a 500

Example fix

// before
curl -X POST --data-binary @req.br -H 'Content-Encoding: br' https://api/endpoint
// after
gzip -c req.json | curl -X POST --data-binary @- -H 'Content-Encoding: gzip' https://api/endpoint

Defensive patterns

Strategy: validation

Validate before calling

func preflight(r *http.Request) error {
    switch r.Header.Get("Content-Encoding") {
    case "", "gzip", "identity":
        return nil
    default:
        return fmt.Errorf("unsupported Content-Encoding %q; use gzip or identity", r.Header.Get("Content-Encoding"))
    }
}

Type guard

func isSupportedEncoding(enc string) bool {
    switch enc {
    case "", "identity", "gzip":
        return true
    }
    return false
}

Try / catch

if err := client.Do(req); err != nil {
    var herr interface{ StatusCode() int }
    if errors.As(err, &herr) && herr.StatusCode() == http.StatusUnsupportedMediaType {
        // resend without Content-Encoding or with gzip
    }
}

Prevention

Set Content-Encoding: gzip explicitly (or omit it) in clients hitting gzip-decoding middleware
Audit proxies/CDNs for automatic br/deflate re-compression of request bodies
Test every client integration against the endpoint with its real headers
Document supported encodings in the API contract

When it happens

Trigger: An HTTP client sends a request to a handler wrapped by this middleware with a Content-Encoding header other than gzip/identity, e.g. curl --data-binary --compressed with br, or an SDK that transparently compresses payloads with deflate/zstd.

Common situations: Clients behind proxies or CDNs that add Content-Encoding: br; misconfigured HTTP clients that set deflate; load tests with zstd-compressed bodies; developers assuming the middleware supports all standard encodings.

Related errors

AI-assisted analysis of ory/hydra@4174065ffb (2026-09-03). Data as JSON: /api/errors/002ac5ce1594e368. Report an issue: GitHub.