https://bugs.openldap.org/show_bug.cgi?id=9719
Issue ID: 9719 Summary: refreshOnly sends empty cookie when client up to date Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs@openldap.org Reporter: ondra@mistotebe.net Target Milestone: ---
Syncprov will send an empty cookie if the consumer has the same cookie as provider. To the best of my knowledge this is not in line with RFC4533 and consumers would effectively drop their cookie when the search finishes.
https://bugs.openldap.org/show_bug.cgi?id=9719
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #0)
Syncprov will send an empty cookie if the consumer has the same cookie as provider. To the best of my knowledge this is not in line with RFC4533 and consumers would effectively drop their cookie when the search finishes.
Pretty sure this has always been the intended behavior, even if not spelled out in the RFC. You can check against the original syncrepl implementation in 2.2.
No bug here. The consumer doesn't update its local cookie if none was received from the provider.
https://bugs.openldap.org/show_bug.cgi?id=9719
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- On Wed, Oct 13, 2021 at 02:22:19PM +0000, openldap-its@openldap.org wrote:
Pretty sure this has always been the intended behavior, even if not spelled out in the RFC. You can check against the original syncrepl implementation in 2.2.
No bug here. The consumer doesn't update its local cookie if none was received from the provider.
The problem is that a cookie is sent and it's an empty string, given the client is supposed to treat them as completely opaque string, there is enough background in the RFC to suggest it should be taken at face value.
I don't think you'd ever suggest TXN implementation in back-mdb sending the same cookie ("") as the transaction identifier should be interpreted by the client in any way either, you just expect it to send it back unmodified. Same here.
https://bugs.openldap.org/show_bug.cgi?id=9719
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #2)
On Wed, Oct 13, 2021 at 02:22:19PM +0000, openldap-its@openldap.org wrote:
Pretty sure this has always been the intended behavior, even if not spelled out in the RFC. You can check against the original syncrepl implementation in 2.2.
No bug here. The consumer doesn't update its local cookie if none was received from the provider.
The problem is that a cookie is sent and it's an empty string, given the client is supposed to treat them as completely opaque string, there is enough background in the RFC to suggest it should be taken at face value.
I don't think you'd ever suggest TXN implementation in back-mdb sending the same cookie ("") as the transaction identifier should be interpreted by the client in any way either, you just expect it to send it back unmodified. Same here.
Nevertheless, one of the motivations behind syncrepl development was to avoid unnecessary chattiness, and this behavior has always been part of the design and implementation. And regardless of cookies being opaque, there is an obvious difference between empty and non-empty.
https://bugs.openldap.org/show_bug.cgi?id=9719
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.7.0 Assignee|bugs@openldap.org |ondra@mistotebe.net Keywords|needs_review |
https://bugs.openldap.org/show_bug.cgi?id=9719
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED Target Milestone|2.7.0 |---
https://bugs.openldap.org/show_bug.cgi?id=9719
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
-
openldap-its＠openldap.org