3 ms·

This is cool and all but why not just expand the scope of GET requests in newer HTTP standards? Maybe have a X-GET-QUERY header to indicate the type if GET req

by _8j50 5y ago

This is cool and all but why not just expand the scope of GET requests in newer HTTP standards? Maybe have a X-GET-QUERY header to indicate the type if GET request? the problem I see with a new method is that it isn't just webservers that need to support it, it is also webapps. Ideally this would be transparent to the webapp (which would just see really big arrays of GET params). The user-agents (browsers) would ideally support this transparently where as with a new method the JS/HTML would need to explicitly support it.

throwoutway 5y ago
Once browsers offer support, the web app+ server would need to support it. Both of those are in control of the devs. The real problem lies in getting infrastructure teams to update the expensive F5 load balancers, and PA/CP/TP firewalls to process the requests. Those aren’t in control of the devs (unless they’re operating together well as a team)
brightstep 5y ago
One of the issues that QUERY solves is that POST is overloaded and is being used for purposes beyond its intended responsibility. Shifting that overloading to GET feels to me like just another hacky approach. I prefer the well-defined, single responsibility that QUERY brings and restores to POST.
wojcikstefan 5y ago
> Maybe have a X-GET-QUERY header to indicate the type if GET request? Note that using the "X-" prefix has been deprecated since 2012: https://datatracker.ietf.org/doc/html/rfc6648 https://datatracker.ietf.org/doc/html/rfc6648
- _8j50 5y ago
  Wow, news to me. Thanks
  - wizzwizz4 5y ago
    Here's the relevant section of the guidelines: https://datatracker.ietf.org/doc/html/rfc6648#section-3 https://datatracker.ietf.org/doc/html/rfc6648#section-3 Creators of new parameters to be used in the context of application protocols: 1. SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or usable across multiple implementations. 2. SHOULD employ meaningful parameter names that they have reason to believe are currently unused. 3. SHOULD NOT prefix their parameter names with "X-" or similar constructs. Note: If the relevant parameter name space has conventions about associating parameter names with those who create them, a parameter name could incorporate the organization's name or primary domain name (see Appendix B for examples).

by _8j50 5y ago

throwoutway 5y ago

Once browsers offer support, the web app+ server would need to support it. Both of those are in control of the devs. The real problem lies in getting infrastructure teams to update the expensive F5 load balancers, and PA/CP/TP firewalls to process the requests. Those aren’t in control of the devs (unless they’re operating together well as a team)

brightstep 5y ago

One of the issues that QUERY solves is that POST is overloaded and is being used for purposes beyond its intended responsibility. Shifting that overloading to GET feels to me like just another hacky approach. I prefer the well-defined, single responsibility that QUERY brings and restores to POST.

wojcikstefan 5y ago

> Maybe have a X-GET-QUERY header to indicate the type if GET request? Note that using the "X-" prefix has been deprecated since 2012: https://datatracker.ietf.org/doc/html/rfc6648 https://datatracker.ietf.org/doc/html/rfc6648

_8j50 5y ago
Wow, news to me. Thanks
- wizzwizz4 5y ago
  Here's the relevant section of the guidelines: https://datatracker.ietf.org/doc/html/rfc6648#section-3 https://datatracker.ietf.org/doc/html/rfc6648#section-3 Creators of new parameters to be used in the context of application protocols: 1. SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or usable across multiple implementations. 2. SHOULD employ meaningful parameter names that they have reason to believe are currently unused. 3. SHOULD NOT prefix their parameter names with "X-" or similar constructs. Note: If the relevant parameter name space has conventions about associating parameter names with those who create them, a parameter name could incorporate the organization's name or primary domain name (see Appendix B for examples).