--- Thijs Kinkhorst <kink@...> wrote:
> On Thursday 24 April 2008 11:18, Thierry Godefroy wrote:
> > (squirrelmail-20080201-SVN_devel-AddressBookHtmlSearch.path), a while ago,
> > for the problems encountered whenever the HTML address book (i.e. the one
> > used to fill up the address fields of an email.
> > Well, I just found out that the attachments are also lost when using the
> > HTML address book search, because while serialized, the attachments are yet
> > not properly urlencoded by addrbook_search_html.php and this results in
> > both an erroneous HTML form, and in an error in compose.php when it tries
> > to urldecode() the unserialized attachments.
> > The attached squirrelmail-20080423-SVN_devel-AddressBookHtmlSearch_v2 patch
> > cures this problem and replaces the previous proposed patch.
> Thanks, I'm not instantly sure about whether this is the best approach,
> encoding them with base64 and urlencoding and serializing them all at once. I
> would have to look in detail at it, which I will do later.
The base64 encoding part is what I added already in the previous version of
this patch because the hidden fields value was not at all escaped by SQM and
resulted in many problems with the HTML address book. I used this approach
rather than urlencoding because, although I did not make any benchmark to
verify it, I believe that base64 encoding is much faster than urlencoding (it's
a one to one character conversion using "brute force", i.e. with no test
whatsoever, while urlencode() first has to check if each character pertains to
the list of characters to encode or not, or to scan the string for such
characters and slice/concatanate: many more tests and/or memory allocations,
and most probably much slower).
I used the urlencoding for the serialized data because the part of the code in
compose.php that uses the value of the corresponding hidden field already used
urldecode() on it (so it was a lesser effort patch, just adding a missing
instruction to restore the proper functionning of the code), but using base64
encoding for everything is probably the thing to do, including elsewhere in SQM
(doing some benchmark to confirm it might be worth it).
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ