Skip to content

fix(router): Render GraphiQL when accepting text/html with highest q-weight#705

Merged
ardatan merged 4 commits intomainfrom
graphiqlhey
Jan 22, 2026
Merged

fix(router): Render GraphiQL when accepting text/html with highest q-weight#705
ardatan merged 4 commits intomainfrom
graphiqlhey

Conversation

@enisdenjo
Copy link
Member

@enisdenjo enisdenjo commented Jan 22, 2026

Closes #704

Now the ResponseMode introduced at #665 will also consider the GraphiQL response mode and negotiate accordingly with browsers that accept both JSON and HTML, but prefer HTML as per the q-weight.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @enisdenjo, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request streamlines the process of serving the GraphiQL interface by integrating its detection directly into the HTTP content negotiation pipeline. It introduces a specific ResponseMode for GraphiQL and modifies the negotiation logic to prioritize text/html for GET requests, ensuring that clients requesting HTML content are correctly served the GraphiQL IDE. This change simplifies the codebase and makes the GraphiQL rendering more consistent with standard content type handling.

Highlights

  • Refactored GraphiQL Rendering Logic: The mechanism for determining when to serve the GraphiQL interface has been overhauled, moving from a separate can_accept_http check to an integrated ResponseMode negotiation.
  • New ResponseMode::GraphiQL: A dedicated GraphiQL variant has been added to the ResponseMode enum, explicitly representing the intent to render the GraphiQL IDE.
  • Prioritized text/html Negotiation for GET Requests: The content type negotiation now considers text/html with higher priority for GET requests, allowing clients that prefer HTML to automatically receive GraphiQL.
  • Removal of can_accept_http: The can_accept_http helper function and its associated logic have been removed, as its functionality is now subsumed by the enhanced content negotiation.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request refactors the content negotiation logic to correctly serve the GraphiQL interface based on the Accept header's q-weights. The changes are well-structured, introducing a ResponseMode::GraphiQL variant and using the headers-accept crate for proper negotiation, which is a significant improvement over the previous string-based check. The logic is now more robust and correct. The tests have also been updated effectively to cover the new behavior, including cases for different HTTP methods.

I have one minor suggestion regarding a piece of dead code that results from an inconsistency between a trait's method signature and its implementation, which could be cleaned up to improve maintainability.

@github-actions
Copy link

k6-benchmark results

     ✓ response code was 200
     ✓ no graphql errors
     ✓ valid response structure

     █ setup

     checks.........................: 100.00% ✓ 235578      ✗ 0    
     data_received..................: 6.9 GB  229 MB/s
     data_sent......................: 92 MB   3.1 MB/s
     http_req_blocked...............: avg=2.82µs   min=647ns   med=1.7µs   max=5.04ms   p(90)=2.55µs  p(95)=2.97µs 
     http_req_connecting............: avg=375ns    min=0s      med=0s      max=1.55ms   p(90)=0s      p(95)=0s     
     http_req_duration..............: avg=18.65ms  min=1.68ms  med=17.7ms  max=107.5ms  p(90)=25.71ms p(95)=29.01ms
       { expected_response:true }...: avg=18.65ms  min=1.68ms  med=17.7ms  max=107.5ms  p(90)=25.71ms p(95)=29.01ms
     http_req_failed................: 0.00%   ✓ 0           ✗ 78546
     http_req_receiving.............: avg=136.86µs min=28.29µs med=45.66µs max=35.97ms  p(90)=83.28µs p(95)=395.9µs
     http_req_sending...............: avg=23.48µs  min=4.85µs  med=10.25µs max=20.17ms  p(90)=15.49µs p(95)=22.58µs
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s      max=0s       p(90)=0s      p(95)=0s     
     http_req_waiting...............: avg=18.49ms  min=1.6ms   med=17.57ms max=106.95ms p(90)=25.44ms p(95)=28.66ms
     http_reqs......................: 78546   2613.353808/s
     iteration_duration.............: avg=19.09ms  min=5.84ms  med=18.02ms max=249.44ms p(90)=26.16ms p(95)=29.47ms
     iterations.....................: 78526   2612.688375/s
     vus............................: 50      min=50        max=50 
     vus_max........................: 50      min=50        max=50 

@github-actions
Copy link

🐋 This PR was built and pushed to the following Docker images:

Image Names: ghcr.io/graphql-hive/router

Platforms: linux/amd64,linux/arm64

Image Tags: ghcr.io/graphql-hive/router:pr-705 ghcr.io/graphql-hive/router:sha-decd0a4

Docker metadata
{
"buildx.build.ref": "builder-12ba1cd7-afc9-4e49-860b-7c83ed354e5a/builder-12ba1cd7-afc9-4e49-860b-7c83ed354e5a0/7alv67vvto2xydiu995tejf1s",
"containerimage.descriptor": {
  "mediaType": "application/vnd.oci.image.index.v1+json",
  "digest": "sha256:9d042eee88ccdd811db4d1d1a438d0ce3ad2d5ec450afecee07481726b511224",
  "size": 1609
},
"containerimage.digest": "sha256:9d042eee88ccdd811db4d1d1a438d0ce3ad2d5ec450afecee07481726b511224",
"image.name": "ghcr.io/graphql-hive/router:pr-705,ghcr.io/graphql-hive/router:sha-decd0a4"
}

@ardatan ardatan merged commit ffc78d9 into main Jan 22, 2026
23 checks passed
@ardatan ardatan deleted the graphiqlhey branch January 22, 2026 17:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No graphiql on router 0.0.33

3 participants