[
https://issues.apache.org/jira/browse/PROTON-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15214500#comment-15214500
]
Rob Godfrey commented on PROTON-1135:
-------------------------------------
As a co-author of the AMQP specification, I don't think it can be taken as read
that every implementation of a "server" MUST support pipelining of the SASL
and AMQP layers together. The spec does lay out that the AMQP open sequence
can be pipelined, but the SASL interaction is (in general) synchronous: the
client must choose from the set of mechanisms offered. In certain
circumstances the client (application) may have knowledge that allows it to
operate in a pipelined manner (e.g. it knows that the server will accept the
mechanism) or may be happy to fail in a reasonably unpleasant way if its
assumptions are incorrect. However I think that it is unreasonable to expect
that in general a peer will accept pipelining SASL and AMQP together, and
empirical evidence shows that it is a poor assumption to make (as literally no
other implementation has supported it out of the box). To my mind, in this
scenario it would be more appropriate to omit the SASL layer entirely.
> [proton-c] dont pipeline SASL and OPEN frames for ANONYMOUS logins by default
> -----------------------------------------------------------------------------
>
> Key: PROTON-1135
> URL: https://issues.apache.org/jira/browse/PROTON-1135
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.12.0
> Reporter: Ganesh Murthy
>
> Dispatch router (which uses Proton-c) currently sends pipelined SASL and OPEN
> frames by default when connecting out to other peers using the ANONYMOUS
> mech, as shown in the following trace -
> {code}
> [0x7f41f80079c0]: -> SASL
> [0x7f41f80079c0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"[email protected]"]
> [0x7f41f80079c0]: -> AMQP
> [0x7f41f80079c0]:0 -> @open(16) [container-id="Qpid.Dispatch.Router.A",
> max-frame-size=65536, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x7f41f80079c0]: <- SASL
> [0x7f41f80079c0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=:ANONYMOUS]
> [0x7f41f80079c0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f41f80079c0]: <- AMQP
> [0x7f41f80079c0]:0 <- @open(16)
> [container-id="ce103199-af03-4d37-bb35-24ad4e55653e", channel-max=32767,
> idle-time-out=8000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"],
> properties={:product="qpid-cpp", :version="0.35", :platform="Linux",
> :host="localhost.localdomain"}]
> {code}
> The AMQP 1.0 spec does not make it clear that this is supported (e.g. see
> diagram below) but in any case various components have shown difficulty with
> it (such as PROTON-1135 just raised, and QPID-6639 which has yet to be
> included in a release but permitted the above protocol trace log).
> {code}
> TCP Client TCP Server
> =========================================
> AMQP%d3.1.0.0 --------->
> <--------- AMQP%d3.1.0.0
> :
> :
> <SASL negotiation>
> :
> :
> AMQP%d0.1.0.0 --------->
> (over SASL secured connection)
> <--------- AMQP%d0.1.0.0
> open --------->
> <--------- open
> {code}
> Proton should by default disable sending pipelined OPEN frames for ANONYMOUS
> logins, to aid compatibility with other components that don't expect/handle
> such behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
