[
https://issues.apache.org/jira/browse/QPID-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810245#comment-17810245
]
ASF GitHub Bot commented on QPID-8648:
--------------------------------------
dakirily opened a new pull request, #234:
URL: https://github.com/apache/qpid-broker-j/pull/234
This PR addresses JIRA
[QPID-8648](https://issues.apache.org/jira/browse/QPID-8648), increasing
maximal frame size before Open frame during SASL negotiation
> [Broker-J] Allow for max frame size >4096 before Open frame (SASL)
> ------------------------------------------------------------------
>
> Key: QPID-8648
> URL: https://issues.apache.org/jira/browse/QPID-8648
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Affects Versions: qpid-java-broker-9.0.0
> Reporter: Dan Langford
> Priority: Major
> Fix For: qpid-java-broker-9.1.1
>
>
> some modern authentication options (XOAUTH2 + JWT) require frames larger then
> 4096. consider if the max frame size (before an Open frame negotiation)
> should be larger or should be configurable with some sort of configuration or
> env variable.
>
> from a discussion on the mailing list
> {quote}The SASL process occurs first, before the Open frame. The Open frames
> are what carries each peers advertised max frame size, mainly aimed at
> later message deliveries. The AMQP 1.0 spec defines before this
> however that the SASL frames can be at-most the 'min max frame size',
> which is fixed at 512 bytes, with no way to negotiate anything larger.
> As you can probably tell, that presents a problem if things in the
> SASL negotiation want to be larger, such as is likely in e.g a newer
> XOAUTH2 mechanism that didnt exist when that decision was originally
> made.
> To simply allow some of these newer alternative mechs to work, it was
> decided to just allow things to exceed the 512byte limit since both
> sides would have to already agree on using a given mech to begin with,
> so doing an alternative like creating a custom multi-challenge
> batching sequence to shuffle the bytes wasnt really going to be adding
> much except significant complexity.
> It appears broker-j allows up to 4096, and you have now found
> something to exceed even that. It doesnt look like it allows
> configuring it, but increasing that seems to be the only option that
> would help here.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
