Tickets :: Comment on [#13153] Bugs in the current implementation for PARTIAL limiting (RFC 5267 [4.4]) in Horde's Imap

* Your Email Address
* Spam protection	Enter the letters below: . ..__ ..___.___. \| \|[__) \|[__ _/ \|/\\|\| \\__\|\| ./__.
Comment	> The current implementation for PARTIAL limiting (RFC 5267 [4.4]) in > Horde_Imap_Client_Socket class needs to be fixed in order to properly > support PARTIAL limiting: > > 1. Using a partial range like 'x:x' breaks the current implementation > for PARTIAL limiting, even though that partial range is perfectly > valid. > > For example, using '1:1' the expected behavior would be to have a > RETURN (PARTIAL 1:1:) in the IMAP command sent to the server. > Something like 'C: 4 UID SORT RETURN (PARTIAL 1:1) (DATE) US-ASCII > UNDELETED'. > > Instead it sends: 'C: 4 UID SORT RETURN (PARTIAL 1) (DATE) US-ASCII > UNDELETED', which is obviously an invalid IMAP command that returns > 'S: 4 BAD Error in IMAP command UID SORT: PARTIAL range broken.' > > This issue is caused by the current behavior of converting the > partial range to ids and then back to its string representation: > strval($this->getIdsOb($options['partial'])); > > To fix this it should just enforce the usage of the provided partial > if it is a valid sequence range ('range_start:range_end'), as > specified in RFC 5267 [4.4]. > > 2. In case there's a 'sort' option the current implementation > conditions the PARTIAL limiting to the availability of the 'SORT' > capability on the 'CONTEXT', even though it also states just below > the check that "RFC 5267 indicates RFC 4466 ESEARCH support, > notwithstanding RFC 4731 support." > and PARTIAL limiting relies on 'ESEARCH' not 'ESORT' to retrive the > message UIDs that correspond to the PARTIAL limiting range that was > specified in the UID SORT command, properly taking into account the > 'sort' criterion: > C: 4 UID SORT RETURN (PARTIAL 1:1) (DATE) US-ASCII UNDELETED > S: * ESEARCH (TAG "4") UID PARTIAL (1:1 1) > S: 4 OK Sort completed (0.000 secs). > > To fix this it should check for the availability of the 'SEARCH' > capability on the 'CONTEXT' as an alternative check that 'ESEARCH' is > available.
Attachment
Watch this ticket

Saved Queries