Re: [PATCH] alt-charset handling in HTTP SMSC module

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: <[email protected]>]

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
-------------------------------------------------------------------