Contrib.social

Enable header-based proactive content negotiation with optimizations and opt-outs available.

Open on Drupal.org →
Created on 25 January 2019, over 5 years ago
Updated 10 May 2024, about 2 months ago

Problem/Motivation

In #2445723: Use the $request format instead of the ContentNegotation. → , we removed Accept header negotiation. That's all well and good for the cases where the client, like a browser, accepts multiple formats, making negotiation difficult. However, in the case of an HTTP API (e.g., JSON:API), a client might specify a single format in the Accept header. In such cases, we know enough to set the request format early in the processing, and should do so to both solve for certain edge-case bugs and optimize retrieval from page cache.

By HEAD not currently honoring an unambiguous Accept header, we have the following bug:
- Perform jQuery.ajax('/node/1', {'headers': {'accept': 'application/json'}}). The client is explicitly asking for JSON and only for JSON. /node/1 is not available in JSON, so the correct response is to return a 406. HEAD currently ignores the Accept header and returns a 200, with the body in HTML format.

Additionally, by HEAD not determining the format from an unambiguous Accept header, modules like JSON:API are adding their own middleware to do it. For example, see #3027980: [upstream] Move FormatSetter from middleware to a route filter, removing conditionality on Accept header → . Except, they're doing it wrong, because they're only checking for the presence of the media type in the Accept header, not that it's the only one there.

Proposed resolution

Expand NegotiationMiddleware::getContentType() to return a format that can be unambiguously determined from the Accept header.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Request processing  →

Last updated about 10 hours ago

No maintainer
Created by

🇺🇸United States effulgentsia

Live updates comments and jobs are added and updated live.
  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024