Hi all!
There's some kannel incompatibility with the iPlanet webserver.
it occurs with samsung handsets c100,t100 (and probably others)
http request produced by kannel in this case is like:
-
GET / HTTP/1.1
Host: wap.samsungmobile.com
Accept: application/vnd.wap.wmlc; type=4365
Accept: application/vnd.wap.wmlc; type=4360
Accept: application/vnd.wap.wmlc; type=1108
Accept: application/vnd.wap.wmlc; level=1.3
Accept: application/vnd.wap.wmlc
Accept: application/vnd.wap.wmlscriptc
Accept: application/vnd.wap.multipart.related
Accept: application/vnd.wap.multipart.mixed
Accept: application/x-up-device
Accept: application/vnd.phonecom.mmc-wbxml; type=4364
Accept: application/vnd.phonecom.mmc-wbxml
Accept: application/vnd.phonecom.im
Accept: application/octet-stream
Accept: application/vnd.openwave.pp
Accept: application/vnd.wap.sic
Accept: application/vnd.wap.slc
Accept: application/vnd.wap.coc
Accept: application/vnd.uplanet.bearer-choice-wbxml
User-Agent: SEC-SGHC100/1.0 UP.Browser/5.0.5.1 (GUI)
Accept-Language: en
Accept: image/vnd.wap.wbmp
Accept: image/png
Accept: application/x-mmc.wallpaper; content-type=img/bmp; size=65536
Accept: application/x-mmc.wallpaper; content-type=img/png; size=65536
Accept: application/x-mmc.picture; content-type=img/bmp; size=65536
Accept: application/x-mmc.picture; content-type=img/png; size=65536
Accept: application/x-mmc.ringtone; content-type=audio/mmf; size=32768
Accept: text/vnd.sun.j2me.app-descriptor
Accept: application/java-archive
Accept: application/vnd.smaf
Accept-Charset: utf-8
Accept: text/vnd.wap.wml
Accept: text/vnd.wap.wmlscript
Accept-Charset: ISO-8859-1
Accept-Charset: ISO-8859-2
Accept-Charset: ISO-8859-3
Accept-Charset: ISO-8859-4
Accept-Charset: ISO-8859-5
Accept-Charset: ISO-8859-6
Accept-Charset: ISO-8859-7
Accept-Charset: ISO-8859-8
Accept-Charset: ISO-8859-9
X_Network_Info: 212.212.212.212
X-WAP-Client-SDU-Size: 32768
Via: WAP/1.1 violator.office.gt.com.ua (Kannel/1.2.1)
X-WAP-Gateway: Kannel/1.2.1
X-WAP-Session-ID: 2
-
http server response:
-
HTTP/1.1 413 Request Entity Too Large
Server: Netscape-Enterprise/6.0
Date: Fri, 30 May 2003 13:07:27 GMT
Content-length: 168
Content-type: text/html
Connection: close
-
Samsungmobile tech. support answer attached. :)
Apparently, problem may be eliminate by packing repeated http-headers,
tested, manualy packed and sent request is working Ok!
But as i look at source
//
void http_header_pack(List *headers)
{
gwlib_assert_init();
gw_assert(headers != NULL);
/* XXX not implemented yet. */
}
:-(
Thanks!
Alexander Pogrebnoy.
GOLDEN TELECOM GSM.
Product & Services.
IT Specialist.
<> <>
GT_WAP_Gateway.doc
Description: MS-Word document
Subject : SFC access problem through kannel WAP G/W
Writer : DaeGyun Chun / /
Written : 2003-06-02 14:11:32
This mail includes SFC hosting team's opinion for the cause of SFC WAP service access
failure through kannel WAP G/W,
and the recommendation for solving kannel WAP G/W problem
[1] SFC hosting team's opinion
1. WAP gateway problem :
The current Ukraine WAP gateway issue is caused by non-standard, Open Source
software.
It is that the requested header information from a handset through the WAP gateway
to our
webserver could be not suitable for our standardized web server.
The resulting "413" error code is a good example.
The error code is caused by the client browser, not by the server.
The current "Service connection incapability" problem seems to be
caused by these reasons.
For reference, Yahoo's web site that is working with the relevant WAP gateway is
running on
Open Source. Actually, I found out that the free OS (operating system) called
FreeBSD and an
unknown webserver is used for Yahoo's site.
You can check it for yourself at the following URL.
http://uptime.netcraft.com/up/graph/?mode_u=on&mode_w=on&site=www.yahoo.de
And in the future the Ukraine WAP gateway, which is not composed by http standard,
could cause a little problem with other WAP services like our contents, photo
service,
and callback service etc.
2. Reasons why we cannot fix the problem on our webserver.
We asked an iPlanet engineer about ways to fix this problem,
and according to his answer, I can tell you that it is impossible
to resize the "Request Header Entity".
The reason is that the value for "Request Header Entity" is already set
inside iPlanet webserver itself, and for resizing this value,
we would have to address the request to Sun.
This means they should create a patch file, which we then have to apply to our
web servers.
But the engineer told me that it is impossible to resize the value, because it is
applied by standardization.
For reference, last year the iPlanet Engineer got a similar request from Samsu
