Am 11.03.2011 18:45, schrieb Stipe Tolj: > committed to svn trunk: > > 2011-03-11 Stipe Tolj <stolj at kannel.org> > * gw/smsc/smsc_http.c: ensure we handle 'alt-charset' correctly, in case > we get DC_UCS2 coding in the payload. > [Message-Id: <4d76bf9c.7070...@tolj.org>]
Hi list, I have reverted this patch due to Alex's veto. Alex tends that we do NOT re-encode if the coding=[1|2], meaning only msg payloads with coding=0 should be re-encoded. I don't see that actually. Looking into gw/smsbox.c code we see that we have 3 options that a msg struct is bassed to bearerbox: a) msg->sms.coding == 0 (aka DC_7BIT), .msgdata is UTF-8 encoded b) msg->sms.coding == 1 (aka DC_8BIT), .msgdata has binary data c) msg->sms.coding == 2 (aka DC_UCS2), .msgdata is UCS-2 encoded ok, let's assume this call to sendsms HTTP interface: http://...&coding=2&text=<url-encoded UCS data> which is a legal injection of a MT message, resulting in a msg passed to bearerbox which is NOT re-encoded at this stage. Now, if this hits the smsc_http and we have an 'alt-charset' set, which means the user wants a re-encoding to a specific charset, then the OLD code won't work out in the smsc_http module. AFAIK, Alex argues that anything coming in with coding=2 should be untouched. Well, this ASSUMES then that a UCS-2 payload can ONLY be injected this way: http://...&coding=0&text=<url-encoded UCS data>&charset=UCS2 to ensure smsbox re-encodes the UCS2 data to UTF-8 internally. IF so, why the heck do we have then coding=2 exposed at the sendsms HTTP interface? Comments please. Stipe -- ------------------------------------------------------------------- Kölner Landstrasse 419 40589 Düsseldorf, NRW, Germany tolj.org system architecture Kannel Software Foundation (KSF) http://www.tolj.org/ http://www.kannel.org/ mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org -------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
