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>> <<mail.txt>>
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 Samsung Securities Company. He should modify the "Header Check Routine" and he requested Sun to do it, but Sun refused the request reasoning that it would violate the standard. [2] request to operator Refer to the attached word file.
