[
https://issues.apache.org/jira/browse/JAMES-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851697#comment-17851697
]
Benoit Tellier commented on JAMES-3552:
---------------------------------------
maxObjectsInGet maxObjectsInSet maxSizeAttachmentsPerEmail had been implemented.
MaxConcurrentRequests and MaxConcurrentRequests still are hard coded.
> Enforce session advertised limits
> ---------------------------------
>
> Key: JAMES-3552
> URL: https://issues.apache.org/jira/browse/JAMES-3552
> Project: James Server
> Issue Type: Sub-task
> Components: JMAP
> Reporter: Benoit Tellier
> Assignee: Antoine Duprat
> Priority: Major
> Fix For: 3.6.0
>
>
> We advertize a bunch of limits in the session:
> {code:java}
> "urn:ietf:params:jmap:core" : {
> "maxConcurrentUpload" : 4,
> "maxSizeRequest" : 10000000,
> "maxConcurrentRequests" : 4,
> "maxCallsInRequest" : 16,
> "maxObjectsInGet" : 500,
> "maxObjectsInSet" : 500
> },
> "urn:ietf:params:jmap:mail" : {
> "maxMailboxesPerEmail" : 10000000,
> "maxMailboxDepth" : null,
> "maxSizeAttachmentsPerEmail" : 20000000
> }
> {code}
> - maxMailboxesPerEmail can likely be null if not enforced
> Regarding maxConcurrentUpload and maxConcurrentRequests enforcing these
> limitations in a distributed environment is a non trivial task... Maybe via
> the use of external API management solutions? In which case we should allow
> an administrator to configure those values according to system wide setting...
> maxSizeRequest, maxCallsInRequest, maxObjectsInGet, maxObjectsInSet,
> maxSizeAttachmentsPerEmail would likely only need some simple validation
> logic to be written.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
