Re: [PATCH] alt-charset handling in HTTP SMSC module
Stipe Tolj <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Organization | tolj.org system architecture |
| Message-ID | <[email protected]> |
Am 12.03.2011 16:52, schrieb Stipe Tolj:
>
> 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.
ok, digging a bit more, I reviewed how our smsc_smpp code does things in this
regard.
For the MT side, msg_to_pd(), the coding == DC_UCS2 is not re-encoded in any
case, means we send UCS2 payload in the .short_message field.
Now, on the MO side, pdu_to_msg(), we catch in a case statement data_coding ==
0x08 (ucs2), and don't re-encode. We set coding == DC_UCS2 here.
So, ergo: IF we expect the MT user to pass a UCS2 message the way I mentioned
above to be re-encoded to UTF-8 internally, then we MUST assume the same for the
MO side, which we don't do.
So, that's why I wanted to handle the coding == DC_UCS2 in the smsc_http to be
able to re-encode that too for an alt-charset.
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
(application/pkcs7-signature, 5.8 KB) - not displayed