Fixed in:
svn://svn.zabbix.com/branches/dev/ZBX-11528

Now zabbix_get will work as per documentation of server request:
https://www.zabbix.com/documentation/3.2/manual/appendix/items/activepassive

(1) Even better consistency could be achieved if checks_agent.c is moved to shared library to be reused both by server and zabbix_get. But it should be decided if needed.

glebs.ivanovskis Yes, src/zabbix_server/poller/checks_agent.c get_value_agent() and src/zabbix_get/zabbix_get.c get_value() have a lot in common and it would be beneficial to merge them into something more general-purpose (and move to src/libs/zbxcommshigh perhaps), especially from the point of view of consistent error messaging and failure analysis (see ZBX-10613). But it's better done in trunk only in a separate issue.
WON'T FIX

A bit of history. New protocol was introduced in

------------------------------------------------------------------------
r4001 | osmiy | 2007-04-14 08:55:37 +0300 (Sat, 14 Apr 2007) | 1 line

 - new comms protocol for ZABBIX agents
------------------------------------------------------------------------

and after that passive checks used new protocol until old one was restored in

------------------------------------------------------------------------
r4049 | alex | 2007-04-23 18:04:46 +0300 (Mon, 23 Apr 2007) | 2 lines

 - do not compile in Curl by default (Alexei)

------------------------------------------------------------------------

(Check the commit message! )

Successfully tested.

Fixed in:
pre-2.2.17rc1 r64274
pre-3.0.7rc1 r64275
pre-3.2.3rc1 r64276
pre-3.3.0 (trunk) r64277

this is a major change in the behaviour - would have been better to implement in trunk only...

For the record: Even if not intended to be used in this combination, Zabbix get cannot be used anymore to make requests to Zabbix Java gateway due to this change.

There are so many documented and half documented loopholes in Zabbix I have to keep in mind and support that I have not a slightest mercy left to such hacks. This is not "a major change in behaviour" this is a restoration of broken backwards compatibility with old agents. I will change my mind if and only if you show me a quote from Zabbix documentation suggesting to use zabbix_get to get values from Java gateway.

my remark was not about usage of zabbix_get with java gateway, it was about changing the protocol in a major way in minor/patchlevel release. it is a major change in the behaviour, even if the goal of restoring compatibility is noble

in the past that has apparently been changed willy-nilly, but it might have been great to rise the standard on that.

i'm not pushing for making this trunk-only change - i'll cope. just commented on the fact that this does not seem to follow good practice.

Before this fix zabbix_get used to use undocumented protocol. After this fix zabbix_get follows the passive check protocol.

You don't use passive checks to poll Java gateway, do you? For probing Java gateway from command line you can use misc/debug/sender.pl (undocumented, though) or create a 50 line script for that particular purpose. Or the best option of all - create a feature request.

ZBX-11977 asks for extending Zabbix get with functionality to make requests towards Zabbix Java gateway.

okkuv9xh, thanks for the feature request.

glebs.ivanovskis, let me clarify - i believe you did the correct thing here, and thank you for spotting this. the only concern i see is doing this in a minor, patchlevel release of stable branches. it does change the behaviour, so somebody doing yum/zypper update etc would wound up with the changed behaviour.
a user could have had deployed scripts, relying on the existing behaviour, documented the workflow - and a patchlevel upgrade suddenly breaks that. that's what users don't expect

while zabbix documentation is great, it is not perfect. one cannot rely on the documentation to describe everything, because it does not - even some major features are completely omitted from the docs.

i'm not saying this should be reverted in any branches at this time. but it might be useful to do functional changes in major releases in the future.

subissue (1) split out in ZBXNEXT-3792

mentioned the change in http://zabbix.org/wiki/Docs/protocols/zabbix_agent/3.2 and other relevant version pages

also mentioned in https://zabbix.org/wiki/Docs/howto/zabbix_get_jmx

vso JMX protocol is changed in ZBXNEXT-1274 now there is only one tag jmx_endpoint, we shall document it in zabbix.org