accepts

Validates the client’s Accept, Accept-Language, Accept-Charset, and Accept-Encoding request headers against the server’s supported values. Returns 406 Not Acceptable when any negotiation fails (configurable).

Pipeline stage: Negotiation

Why 'accepts'?

The name maps directly to the HTTP Accept header family per RFC 9110 §12.5 — it is a verb form of the protocol concept, not a generic “does this accept X?” helper. Full naming rationale →

Import

import {accepts} from '@centralping/ergo';

Options

Option	Type	Default	Description
throwIfFail	boolean	true	Return 406 when any negotiated value is undefined
types	string[]	—	Acceptable media types
languages	string[]	—	Acceptable languages
charsets	string[]	—	Acceptable character sets
encodings	string[]	—	Acceptable content encodings

Return Value

On success, the middleware returns a negotiation result stored on the domain accumulator at acc.accepts:

{
  type: 'application/json',
  language: 'en',
  charset: 'utf-8',
  encoding: 'identity'
}

Each key corresponds to the best match for the respective header. When no constraint is provided for a key, the negotiated value is the client’s top preference.

Error Responses

Status	Condition
406 Not Acceptable	Any negotiated value is undefined and throwIfFail is true

The detail field in the RFC 9457 response identifies which header failed: Failed to negotiate content for: [Accept].

Usage

Standalone

import {compose, accepts} from '@centralping/ergo';

const pipeline = compose(
  accepts({types: ['application/json']}),
  // acc.accepts.type === "application/json"
);

ergo-router

router.get('/users', {
  accepts: {types: ['application/json']},
  execute: (req, res, acc) => ({
    response: {body: users},
  }),
});

RFC References

• RFC 9110 §12.5 — Content Negotiation

API Reference

See the auto-generated accepts API docs.