arturobernalg commented on PR #499: URL: https://github.com/apache/httpcomponents-core/pull/499#issuecomment-2424176249
> > > > I have a couple of concerns regarding the addition of the QUERY method: > > > > > > > > > Sure > > > > ``` > > > > * Lack of Standardization: The QUERY method isn't defined in any official HTTP specification (like RFC 7231). Adding a non-standard method could lead to compatibility issues and confusion, especially since users might assume it's widely recognized. Should we really be adding this as a core method, or is there a specific context or internal protocol that necessitates this? > > > > ``` > > > > > > > > > There is a draft in progress for it: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/ > > > > ``` > > > > * Content-Enclosing Method: The change marks QUERY as a content-enclosing method, similar to POST, PUT, and PATCH. This seems unconventional since typical query operations (like GET) don't usually involve a request body. What’s the rationale behind allowing QUERY to enclose content > > > > ``` > > > > > > > > > The main purpose of QUERY is to be a GET with body. > > > > > > I wonder what the likelihood is of this graduating from draft status. There must be a ton of drafts that have gone nowhere... > > I think it's likely to graduate "soon". The [document](https://github.com/httpwg/http-extensions/commits/main/draft-ietf-httpbis-safe-method-w-body.xml) is being refined lately and [discussion](https://github.com/httpwg/http-extensions/issues?q=is%3Aissue+label%3Aquery-method+) is pretty healthy First, about the standardization aspect: relying on a draft, no matter how 'soon' you think it will graduate, is risky. We can't build a reliable core library on something that might become a standard. Drafts come and go; many have promising discussions and then disappear. If this draft does become an RFC, great—we can add support then. Until that point, we should not prematurely introduce something that carries compatibility risk without any guarantee. As for adding the QUERY method to support use cases like GET with a body: IMO Many server implementations can/will handle such requests inconsistently, leading to unpredictable behavior. There is no widespread consensus among major HTTP servers to support GET with a body, and adding this as a content-enclosing method doesn't align with current expectations of how safe and idempotent methods operate. Regarding the Javadocs, I agree with @garydgregory . If we're adding public methods, they must be properly documented according to the Apache standards, including the @since tags, parameter descriptions, and proper guidance on usage. The fact that some existing methods lack Javadocs is not an excuse to perpetuate this issue. We should be raising the bar, not repeating past shortcomings. Finally, it would also be better if this PR came with a proper test case. Proper tests ensure we catch edge cases and unintended consequences before this ends up in users' hands. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
