[jira] [Updated] (QPID-8648) [Broker-J] Allow for max frame size >4096 before Open frame (SASL)

["Daniil Kirilyuk (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/QPID-8648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniil Kirilyuk updated QPID-8648:
----------------------------------
    Summary: [Broker-J] Allow for max frame size >4096 before Open frame (SASL)  (was: allow for max frame size >4096 before Open frame (SASL))

> [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
>
> 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org