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