fix: Allow POST requests without Content-Type header when body is empty

[kabir]

Per RFC 9110 §8.3, Content-Type header is only meaningful when a message body is present. The HTTP+JSON transport was incorrectly returning 415 (ContentTypeNotSupportedError) for POST requests with no body and no Content-Type header.

This fix adds validateContentTypeForOptionalBody() method to handle endpoints like POST /tasks/{id}:cancel where the body is optional. When the body is null or empty, Content-Type validation is skipped. When body content is present, Content-Type must still be application/json.

This allows bodyless POST requests to be processed correctly and return appropriate errors (404 TaskNotFoundError, 409 TaskNotCancelableError) instead of 415.

Fixes #747 🦕

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 resolves an issue where HTTP POST requests lacking a body but also a Content-Type header were incorrectly rejected with a 415 'ContentTypeNotSupportedError'. By implementing a new validation logic that respects RFC 9110's guidance on Content-Type header applicability, the system now correctly processes bodyless POST requests, allowing for appropriate business logic errors (like 404 or 409) to be returned instead of a generic content type error.

Highlights

• Content-Type Validation: POST requests with an empty body no longer require a Content-Type header, aligning with RFC 9110 §8.3.
• New Validation Method: A new private method, validateContentTypeForOptionalBody, was introduced to conditionally validate the Content-Type header only when a request body is present.
• Endpoint Update: The cancelTask endpoint was updated to utilize the new validateContentTypeForOptionalBody method, preventing incorrect 415 errors for bodyless requests.

Changelog

• reference/rest/src/main/java/io/a2a/server/rest/quarkus/A2AServerRoutes.java
  • Modified the cancelTask method to use the new validateContentTypeForOptionalBody method.
  • Added a new private method validateContentTypeForOptionalBody to handle conditional Content-Type validation based on the presence of a request body.

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. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses an issue where POST requests with an empty body were incorrectly rejected due to a missing Content-Type header. The introduction of validateContentTypeForOptionalBody is a clean solution that correctly handles endpoints with optional bodies, like cancelTask. The implementation is sound and follows the logic described in the RFC. I have one minor suggestion to further improve the code.