Re: [PATCH] HTTP Redirect Fix
Jonathan Houser wrote: The HTTP redirects were failing because indeed Kannel was trying to read a body that wasn't there. The patch adds a check for a length of 0 as specified by Content-Length, and if found it sets the state to entity_done. This all happens in deduce_body_state() within http.c. Attached is the diff of my code vs. CVS. This fixed both my local WAP homepage redirect and the Hotmail redirect. ok, this is a bug. But nothing to do in general with redirecting (HTTP 302). I'll file a bug to mantis to keep this documented. Stipe mailto:stolj_{at}_wapme.de --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ ---
Re: [PATCH] HTTP Redirect Fix
Stipe, ok, this is a bug. But nothing to do in general with redirecting (HTTP 302). Yeah, I had originally put in a fix where I looked for HTTP_FOUND somewhere else in the code and set the entity_done flags there. But then I tracked it deeper to being an issue with the Content-Length, which is what the patch fixed. Jon
Re: [PATCH] HTTP Redirect Fix
Jonathan Houser wrote: Index: gwlib/http.c === RCS file: /home/cvs/gateway/gwlib/http.c,v retrieving revision 1.231 diff -u -p -d -r1.231 http.c --- gwlib/http.c 29 Mar 2005 12:57:16 - 1.231 +++ gwlib/http.c 6 Apr 2005 17:42:17 - @@ -359,6 +359,7 @@ typedef struct { static void deduce_body_state(HTTPEntity *ent) { Octstr *h = NULL; +long ret; if (ent->expect_state == expect_no_body) { ent->state = entity_done; @@ -383,11 +384,13 @@ static void deduce_body_state(HTTPEntity h = http_header_find_first(ent->headers, "Content-Length"); if (h != NULL) { -if (octstr_parse_long(&ent->expected_body_len, h, 0, 10) == -1 || -ent->expected_body_len < 0) { +ret = octstr_parse_long(&ent->expected_body_len, h, 0, 10); +if (ret == -1 || ent->expected_body_len < 0) { error(0, "HTTP: Content-Length header wrong: <%s>", octstr_get_cstr(h)); ent->state = body_error; +} else if ( ent->expected_body_len == 0 ) { +ent->state = entity_done; } else { ent->state = reading_body_with_length; } +1, commited to cvs in slight variation. At least the long ret seems to me absolutely unnecessary, as it has been obviously more for debugging purporses Jonathan, right? ;) Stipe mailto:stolj_{at}_wapme.de --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:info_{at}_wapme-systems.de http://www.wapme-systems.de/ ---
Re: protocol for java box application development
Hello all ! The answer is Yes! The thing is, that it might be by summer, and don't know very well yet the licensing, because it is a thesis project. But it is for sure that eventually will be open source completely :). The status is, almost complete, I'm testing the SMSbox functionality but don't have plans to enable the WAPbox functionality in short term, but in such a case is not that big deal. I'm sending here the javadoc so you could start planning your applications in the while. Cheers! == Oscar On Wed, 2005-04-06 at 15:36, Hillel Bilman wrote: > Dear Oscar, > > Are you going to release the Kannel's native protocol for the java box > application development to the Kannel group? > as I program in Java and would like to test it. > Maybe you can start a project at Source Forge where you release your code > and have many people that way contribute to it. > > Best Regards > Hillel > > kjProtocol.tgz Description: application/compressed-tar
[PATCH] Addition Of http-proxy-port-exceptions
This patch adds an 'http-proxy-port-exceptions' config file option to Kannel. The purpose of this is to allow you to skip using your proxy server for certain types of traffic. I added it specifically for SSL. So an example config file might look like: http-proxy-host = localhost http-proxy-port = 80 http-proxy-port-exceptions = 443 I realize that there is already an 'http-proxy-exceptions' in Kannel that does the same trick. However I'd rather not have to maintain a big list of hostnames I have to add to each time a subscriber finds some new SSL site. A list of ports is not so bad, especially since almost everyone will use 443 for SSL. To not break compatability, I also added 'E' options to test_http.c and test_xmlrpc.c (where 'e' is exceptions and the new 'E' is port_exceptions). I have tested this patch for trying to access Hotmail (which didn't work before), and it works fine. Thanks. Jon Index: gw/smsbox.c === RCS file: /home/cvs/gateway/gw/smsbox.c,v retrieving revision 1.257 diff -u -p -d -r1.257 smsbox.c --- gw/smsbox.c 22 Feb 2005 16:22:03 - 1.257 +++ gw/smsbox.c 7 Apr 2005 15:26:34 - @@ -3265,6 +3265,7 @@ static Cfg *init_smsbox(Cfg *cfg) Octstr *http_proxy_host = NULL; long http_proxy_port = -1; List *http_proxy_exceptions = NULL; +List *http_proxy_port_exceptions = NULL; Octstr *http_proxy_username = NULL; Octstr *http_proxy_password = NULL; int ssl = 0; @@ -3300,6 +3301,8 @@ static Cfg *init_smsbox(Cfg *cfg) octstr_imm("http-proxy-password")); http_proxy_exceptions = cfg_get_list(grp, octstr_imm("http-proxy-exceptions")); +http_proxy_port_exceptions = cfg_get_list(grp, + octstr_imm("http-proxy-port-exceptions")); #ifdef HAVE_LIBSSL conn_config_ssl(grp); @@ -3455,13 +3458,14 @@ static Cfg *init_smsbox(Cfg *cfg) if (http_proxy_host != NULL && http_proxy_port > 0) { http_use_proxy(http_proxy_host, http_proxy_port, http_proxy_exceptions, http_proxy_username, - http_proxy_password); + http_proxy_password, http_proxy_port_exceptions); } octstr_destroy(http_proxy_host); octstr_destroy(http_proxy_username); octstr_destroy(http_proxy_password); gwlist_destroy(http_proxy_exceptions, octstr_destroy_item); +gwlist_destroy(http_proxy_port_exceptions, octstr_destroy_item); return cfg; } Index: gw/wapbox.c === RCS file: /home/cvs/gateway/gw/wapbox.c,v retrieving revision 1.177 diff -u -p -d -r1.177 wapbox.c --- gw/wapbox.c 22 Feb 2005 16:20:52 - 1.177 +++ gw/wapbox.c 7 Apr 2005 15:26:34 - @@ -496,6 +496,7 @@ static void config_reload(int reload) { Octstr *http_interface_name; long http_proxy_port; List *http_proxy_exceptions; +List *http_proxy_port_exceptions; Octstr *http_proxy_username; Octstr *http_proxy_password; int warn_map_url = 0; @@ -527,15 +528,17 @@ static void config_reload(int reload) { http_proxy_username = cfg_get(grp, octstr_imm("http-proxy-username")); http_proxy_password = cfg_get(grp, octstr_imm("http-proxy-password")); http_proxy_exceptions = cfg_get_list(grp, octstr_imm("http-proxy-exceptions")); +http_proxy_port_exceptions = cfg_get_list(grp, octstr_imm("http-proxy-port-exceptions")); if (http_proxy_host != NULL && http_proxy_port > 0) { http_use_proxy(http_proxy_host, http_proxy_port, http_proxy_exceptions, http_proxy_username, - http_proxy_password); + http_proxy_password, http_proxy_port_exceptions); } octstr_destroy(http_proxy_host); octstr_destroy(http_proxy_username); octstr_destroy(http_proxy_password); gwlist_destroy(http_proxy_exceptions, octstr_destroy_item); +gwlist_destroy(http_proxy_port_exceptions, octstr_destroy_item); grp = cfg_get_single_group(cfg, octstr_imm("wapbox")); if (grp == NULL) { Index: gwlib/cfg.def === RCS file: /home/cvs/gateway/gwlib/cfg.def,v retrieving revision 1.110 diff -u -p -d -r1.110 cfg.def --- gwlib/cfg.def 11 Feb 2005 15:35:48 - 1.110 +++ gwlib/cfg.def 7 Apr 2005 15:26:34 - @@ -108,6 +108,7 @@ SINGLE_GROUP(core, OCTSTR(http-proxy-host) OCTSTR(http-proxy-port) OCTSTR(http-proxy-exceptions) +OCTSTR(http-proxy-port-exceptions) OCTSTR(http-proxy-username) OCTSTR(http-proxy-password) OCTSTR(ssl-client-certkey-file) Index: gwlib/http.c === RCS file: /home/cvs/gateway/gwlib/http.c,v retrieving revision 1.232 diff -u -p -d -r1.232 http.c --- gwlib/http.c7 Apr 2005
Character Set Question (WAP)
A basic question for the developers. In the WAP side of things, all traffic is converted it seems to UTF-8 before being 'compiled'. Yet the Character Set is being sent to the phone as the incoming one. Is this the way it should work? (Or should the Character Set be UTF-8?) I ask because a specific site (tagtag) sends a Character Set of ISO-8859-2 which the end user phones we've tested with don't understand. Nor does my WapIDE phone simulator. ISO-8859-1, like what my personal WAP server sends, work fine. I am just wondering if I could make a patch to send the Character Set as UTF-8 in all cases (or at least those where it's converted first) and not break any rules. Thanks in advance. Jon P.S. The web site URL giving me issues is: http://tagtag.com/site/wapdir/index.php This is with a GSM handset so you may be able to test and get the same results. I found the Character Set being sent via tcpdump and ethereal as it's not listed in the debug output from Kannel.
Re: Character Set Question (WAP)
A basic question for the developers. In the WAP side of things, all traffic is converted it seems to UTF-8 before being 'compiled'. Yet the Character Set is being sent to the phone as the incoming one. Is this the way it should work? (Or should the Character Set be UTF-8?) I ask because a specific site (tagtag) sends a Character Set of ISO-8859-2 which the end user phones we've tested with don't understand. Nor does my WapIDE phone simulator. ISO-8859-1, like what my personal WAP server sends, work fine. I am just wondering if I could make a patch to send the Character Set as UTF-8 in all cases (or at least those where it's converted first) and not break any rules. Thanks in advance. Jon P.S. The web site URL giving me issues is: http://tagtag.com/site/wapdir/index.php This is with a GSM handset so you may be able to test and get the same results. I found the Character Set being sent via tcpdump and ethereal as it's not listed in the debug output from Kannel. Looks like it's the Character Set in the Jon
Re: Character Set Question (WAP)
Replying to Jonathan Houser: > >This is with a GSM handset so you may be able to test and get the same > >results. I found the Character Set being sent via tcpdump and ethereal > >as it's not listed in the debug output from Kannel. > > Looks like it's the Character Set in the encoding=) that's causing the problem. I checked the code and stumbled > across a TODO. Guess I'll look into DOing it. Thanks. Looks that you're one of a few people who actually using kannel as a wap gateway, not as smsrouter. Take a look at my patchset. It worth it. In particular, almost all of charset problems are solved here. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head Index: gateway.C8/configure.in === --- gateway.C8.orig/configure.in2005-04-01 16:08:46.997722376 +0400 +++ gateway.C8/configure.in 2005-04-01 16:08:50.242239063 +0400 @@ -213,6 +213,18 @@ ] ) +AC_MSG_CHECKING([whether to do all wapbox xml processing in utf-8]) +AC_ARG_ENABLE(scharset, +[ --enable-scharset do all wapbox xml processing in utf-8], +[ + if test "$enableval" != yes; then +AC_MSG_RESULT(no) + else +AC_MSG_RESULT(yes) +AC_DEFINE(NEW_CHARSETS, 1, [Simplify wapbox charset processing]) + fi +]) + dnl Extra feature checks dnl GW_HAVE_TYPE_FROM(HDRNAME, TYPE, HAVENAME, DESCRIPTION) Index: gateway.C8/gw/wap-appl.c === --- gateway.C8.orig/gw/wap-appl.c 2005-04-01 16:08:47.000721930 +0400 +++ gateway.C8/gw/wap-appl.c2005-04-01 16:08:50.244238765 +0400 @@ -523,6 +523,10 @@ * to handle those charsets for all content types, just WML/XHTML. */ static void add_charset_headers(List *headers) { +#ifdef NEW_CHARSETS +if (!http_charset_accepted(headers, "utf-8")) +http_header_add(headers, "Accept-Charset", "utf-8"); +#else long i, len; gw_assert(charsets != NULL); @@ -532,6 +536,7 @@ if (!http_charset_accepted(headers, charset)) http_header_add(headers, "Accept-Charset", charset); } +#endif } @@ -720,6 +725,23 @@ } +static void strip_preamble(Octstr *document) { + long gt = 0, enc = 0; +Octstr *text = NULL, *encoding = NULL; + +encoding = octstr_imm(" encoding"); +enc = octstr_search(document, encoding, 0); +gt = octstr_search_char(document, '>', 0); + +if (enc > 0 && gt > enc) { + gt++; + text = octstr_copy(document, gt, octstr_len(document) - gt); + octstr_truncate(document, 0); + octstr_append_data(document, octstr_get_cstr(text), octstr_len(text)); + octstr_destroy(text); +} +} + /* * Return an HTTP reply back to the phone. */ @@ -865,12 +887,30 @@ /* get charset used in content body, default to utf-8 if not present */ if ((charset = find_charset_encoding(content.body)) == NULL) +#ifdef NEW_CHARSETS +if (octstr_len(content.charset) > 0) { +charset = octstr_duplicate(content.charset); +} else { +charset = octstr_imm("UTF-8"); +} +#else charset = octstr_imm("UTF-8"); +#endif /* convert to utf-8 if original charset is not utf-8 * and device supports it */ -if (octstr_case_compare(charset, octstr_imm("UTF-8")) < 0 && +#if 0 +if (octstr_case_compare(charset, octstr_imm("UTF-8")) != 0) { +debug("wsp",0,"Converting wml/xhtml from charset <%s> to UTF-8", +octstr_get_cstr(charset)); +if (charset_convert(content.body, octstr_get_cstr(charset), "UTF-8") >= 0) { +octstr_destroy(content.charset); +content.charset = octstr_create("UTF-8"); +} +} +#else +if (octstr_case_compare(charset, octstr_imm("UTF-8")) != 0 && !http_charset_accepted(device_headers, octstr_get_cstr(charset))) { if (!http_charset_accepted(device_headers, "UTF-8")) { warning(0, "WSP: Device doesn't support charset <%s> neither UTF-8", @@ -883,6 +923,7 @@ octstr_get_cstr(charset), "UTF-8") >= 0) { octstr_destroy(content.charset); content.charset = octstr_create("UTF-8"); +strip_preamble(content.body); /* XXX it might be good idea to change */ } } @@ -890,7 +931,7 @@ /* convert to iso-8859-1 if original charset is not iso * and device supports it */ -else if (octstr_case_compare(charset, octstr_imm("ISO-8859-1")) < 0 && +else if (octstr_case_compare(charset, octstr_imm("ISO-8859-1"))