comparison libpurple/protocols/oscar/oscar.c @ 16832:9f9c486a8aca

flags of 0x00 in oscar_icon_req() can apparently mean 'you should upload your buddy icon' just as flags of 0x41 can. I'm really unclear as to why Adium with libpurple is getting the 0x00 response while Pidgin with the same libpurple code is getting 0x41 after sending identical data (with identical md5 hashes) for a buddy icon... but that's the way it is. This may fix other conditions in which AIM people claim that their buddy icon isn't being properly set; further insight into what's going on would certainly be appreciated.
author Evan Schoenberg <evan.s@dreskin.net>
date Thu, 03 May 2007 19:12:19 +0000
parents f0b4efc4a83a
children 5ade68b6a410
comparison
equal deleted inserted replaced
16823:f0b4efc4a83a 16832:9f9c486a8aca
5569 case 0x0001: { 5569 case 0x0001: {
5570 flags = va_arg(ap, int); 5570 flags = va_arg(ap, int);
5571 length = va_arg(ap, int); 5571 length = va_arg(ap, int);
5572 md5 = va_arg(ap, guchar *); 5572 md5 = va_arg(ap, guchar *);
5573 5573
5574 if (flags == 0x41) { 5574 if ((flags == 0x00) || (flags == 0x41)) {
5575 if (!flap_connection_getbytype(od, SNAC_FAMILY_BART) && !od->iconconnecting) { 5575 if (!flap_connection_getbytype(od, SNAC_FAMILY_BART) && !od->iconconnecting) {
5576 od->iconconnecting = TRUE; 5576 od->iconconnecting = TRUE;
5577 od->set_icon = TRUE; 5577 od->set_icon = TRUE;
5578 aim_srv_requestnew(od, SNAC_FAMILY_BART); 5578 aim_srv_requestnew(od, SNAC_FAMILY_BART);
5579 } else { 5579 } else {