Accept-Query

Servers advertise support for the QUERY method through the Accept-Query response header. The header lists the media types a resource accepts in QUERY request bodies, so clients learn about method support and accepted query formats at the same time.

Table of Contents

Usage
Values
- media-range
- Wildcards
Example
A structured field wearing an Accept name
See also

Usage

The Accept-Query response header signals that the target resource supports the QUERY method and identifies the query format media types the resource accepts. A client reading the header learns both that QUERY requests are supported and which Content-Type values the resource processes. The header was standardized alongside the QUERY method in June 2026 and holds a permanent IANA registration.

The header parallels Accept-Post and Accept-Patch, which advertise accepted media types for POST and PATCH requests. The Allow header lists supported methods by name, while Accept-Query pairs method support with format information in a single field.

Despite the visual similarity to Accept, the header is a Structured Fields List and is parsed under Structured Fields rules rather than the classic media range grammar. Each list member is a Token or a String carrying a media range without parameters. Media type parameters map to Structured Field parameters attached to the member. Recipients treat Tokens and Strings as equivalent, and the order of the listed types carries no significance.

The field value applies to every URI on the server sharing the same path. The query component of the URI is ignored. When responses for the same resource return different Accept-Query values, the most recently received fresh value wins, following standard cache freshness rules.

A common placement is the 415 Unsupported Media Type response. When a QUERY request arrives with an unsupported format, including Accept-Query in the error response directs the client toward a format the resource processes.

Values

media-range

A Token or String naming a media type or media range, such as application/sql or "application/jsonpath". The String form is required when the value falls outside the Token grammar, for example a type starting with a digit. Parameters such as charset attach as Structured Field parameters after a semicolon.

Wildcards

The wildcard */* matches any media type. A partial wildcard such as text/* matches any subtype of the named type. These two forms are the only supported wildcard patterns.

Example

A server advertising two accepted query formats. Clients send QUERY bodies as GraphQL or SQL, with the matching Content-Type header identifying the chosen format.

Accept-Query: application/graphql, application/sql

A response combining a quoted String with a parameterized Token, as shown in the specification. The quotes around application/jsonpath are Structured Fields String syntax and carry no special meaning. The charset="UTF-8" parameter attaches to application/sql.

Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"

A 415 response guiding a client toward a supported format after a QUERY request with an unsupported media type. The client retries with a GraphQL body and succeeds.

HTTP/1.1 415 Unsupported Media Type
Accept-Query: application/graphql

A structured field wearing an Accept name

Accept-Query looks like the Accept family and parses differently: the value is a structured-field list of tokens or strings, without quality values, without significant ordering, and with wildcards limited to */* and whole-subtype forms such as text/*. A parser treating the header as a classic Accept value breaks on the first quoted string.

Scope is the surprising rule. The advertised value applies to every URI on the server sharing the same path, with query components ignored, and the most recently received fresh value wins where responses disagree.

Presence doubles as capability discovery, declaring the QUERY method supported while naming the query formats accepted. The specification discovers method support through OPTIONS and the Allow header, and format support through a HEAD request reading this field. The blunt alternatives are trying a QUERY and reading Allow from a 405, or reading the accepted formats from a 415.

Adoption tracks the young method: implementations remain scarce across servers, frameworks, and edges, so the header is a specification to build against rather than a deployed reality.