Closed murali-shris closed 3 months ago
Should we restrict the length to 248 if it doesn't start with "cached:"? Leaves enough for a "cached:"prefix to be added on a caching atServer / client
sure Gary.
Should we restrict the length to 248 if it doesn't start with "cached:"? Leaves enough for a "cached:"prefix to be added on a caching atServer / client
sure Gary.
@gkc I had a discussion with @sitaram-kalluri on this. Let's say the key is @ bob: phone@ alice. This will be stored in alice's keystore. If the key has ttr, then @ bob will cache the key at his end. 255 char limit will be enforced at bob's keystore including cached: In persistence layer, 255 can be the max limit in client/server, 248 without cached: and 255 including cached: is this fine?
Should we restrict the length to 248 if it doesn't start with "cached:"? Leaves enough for a "cached:"prefix to be added on a caching atServer / client
sure Gary.
@gkc I had a discussion with @sitaram-kalluri on this. Let's say the key is @ bob: phone@ alice. This will be stored in alice's keystore. If the key has ttr, then @ bob will cache the key at his end. 255 char limit will be enforced at bob's keystore including cached: In persistence layer, 255 can be the max limit in client/server, 248 without cached: and 255 including cached: is this fine?
Yes I believe so
fixes: https://github.com/atsign-foundation/at_server/issues/1863 - What I did
point to persistence branch and run at_client and server tests https://github.com/atsign-foundation/at_client_sdk/pull/1281 https://github.com/atsign-foundation/at_server/pull/1877
With this fix, server will return data:null when updating key with length > 255 chars. Have to make fix in server to return correct error message.