|
wojciech.kapcia@tigase.net opened 4 years ago
|
|
@wojtek it looks like there is some issue that make unable for Beagle to know that it already has that avatar. I'm checking if file is on disk, so it would suggest that it is removed what is possible as macOS may occasionally clean this temporary folder. Another thing may be that the image data do not match hash calculated by Beagle. Could you check that for this people avatars are shown? (if not, that would suggest hash do not match data). |
|
|
It seems that the avatar is not there: Full payload. |
|
|
Just out curiosity I checked if the image matches the hash and it does: Btw. Can Beagle handle webp? and wouldn't the format prevent it from saving it and thus skipping being cached? |
|
|
The issue is not even with BeagleIM being able to handle a format of a file but the XML which is sent as a vcard. (I'm saving data without checking if I can present the image). According to XEP-0153:
I suppose that, as I require However, XEP has SHOULD as it is expected from the clients to send Moreover, our VCard4<->VCardTemp converter in Tigase also requires So the question here is, how to solve it. On one side, it is allowed but not recommended to send |
|
|
@wojtek What do you think? |
|
|
OK, we have a couple of issues here and it boils down to user using non-standard filetype - it's not on the list in specification -> What we could/should do:
|
|
|
We need this type (mimetype) to create data URI from base64 encoded binary data, ie. from type |
|
|
OK, but as I said (regarding (3)) - in the worst case scenario (someone not sending However, the gist of this issue is (1) (and to some extend (2)). I'm not sure if we should dedicate time to (3) |
|
|
OK, I just noticed another thing (which seems to discard theory about missing TYPE) - even with payloads that have TYPE the avatar/picture is not stored: This morning presence was received, Beagle queried for avatar and got it. After restart it happened again (and nothing was saved in cache path) |
|
|
I'm not sure why this file was not created, however I suppose that there could be a case when file could be removed (I do not know how or when, but I see that this could be possible). I've improved VCard API to return more details to the client and improved logging so we could always check. I've also relaxed restriction related to requirement of |
|
|
It seems to still be happening with version Version 4.1 (104) Yet no file is saved: This particular account was queried at: I noticed this one is also not stored And there is also one with empty vcard, but I'd say it's an outlier (and I'm not sure we should handle it): |
|
|
I'm going to start with some answers for each example and then sum up. For Namespace is correct but the element name is not. It should be As for while extracted photo from fetched vCard returns: as you can see As you can see we have 2 cases which can be generalized to a single case: User's client advertises photo hash of vCard photo which does not match!. It does not matter if there is invalid vCard or a vCard without photo or a vCard without photo which hash matches. It basically means that I do not have anything to display and as I'm receiving photo hash of unknown photo I need to query those JIDs for vCard every damn time. That is an issue with vCard-temp protocol and it cannot be easily overcome. I cannot cache If you wish, we can discuss this, but current behaviour is correct. btw. I've even encountered some clients sending UUID as a photo hash, so I've added validation if photo hash is a correct SHA1 result. |
|
|
btw. You can run following command from the console and it will return avatars photo hashes which it looks for and number of photos found in the vCard (not a number of matching photos): |
|
|
Regarding lowercase: https://github.com/maranda/metronome/issues/526 Regarding mismatch in published and calculated hash: I brought the topic in jdev MUC but without much discussion / nothing conclusive (this is how things works/doesn't work, period). Let's consider it "done" as it works now according to the specification. We can't help with misbehaving clients. |
|
|
I agree. We could close it. |
| Type |
Bug
|
| Priority |
Normal
|
| Assignee | |
| Version |
4.1
|
| Spent time |
10h
|
Issue Votes (0)
Watchers (0)
(maybe related to #issue #143)
I noticed that BeagleIM is still somewhat "chatty" in the XML console. I took a look and it seems that avatar cache is not working correctly (?!).
Yesterday following stanza exchange took place (connect to conversations room, receive presence from participants with photo info):
Which resulted in query for actual photo payload:
Today, during same flow for the same user with the same photo hash the photo was queried again:
(binval is about 10K)