Bruno Rodrigues wrote: > > I don't think it's a HTTP server problem. I have devices that sends way > too many headers (more than 30 accepts if I remember) and a Cisco > "alteon alike" just dropped my connection with those many headers. > > I guess what we are doing now is the right thing. ;)
hmmm, yeah maybe. AFAIR there is no hard limit in RFC2818 (HTTP/1.1) for *how many* accept headers are allowed to be passed. > Yep, SE looked at wml-1.1 and POST'ed with appl/x-www-urlencoded. As > soon as I set wml1.3, it POST's with right appl/mult.form-data. ahhhhhh. > >> 2003.07.18 - smsbox - mo-recode now tries to also recode to utf-8 if iso > >> fails. for external servers, it's easier to process utf8 than ucs2/utf16 > >> (documented) > > > > +0. > > This is important to help our "clients", and besides you'll get a nice > string text in logs instead of a 00xx00xx00xx... ;) agreed. > >> 2003.07.20 - broken smsbox compatibility to enable mclass=0..3, > >> coding=0..2 and pid=0..255. This was already talked about and it's > >> required to be able to set pid=0 and to be consistent with specification > >> (it's dificult to explain to someone that for etsi's message class 0 you > >> need to set kannel's mclass to 1) > > > > yep, +1. Did you test all dependencies on this?! > > I've done some tests with at(2) (I was at home), which tested smsbox > code and sms.c code (fields<->dcs), so it should work with all the > others. > SMAPI is using directly sms.mclass and other parameters, but I guess > I've also fixed it. we'll see as soon as we update our production server that run some SM/ASI links ;) > >> 2003.07.20 - maintained parameter consistency and always use urlencoding > >> for udh and binary data in POST headers and in xml. I had several > >> complains because common sense will make you send url-encode in http > >> udh header and then you ask yourself why is it not working > > > > ??? (didn't get the point. too less coffee this morning? ;)) > > in query-string, udh=%xx%yy%zz. In http headers, you use udh=xxyyzz, in > my xml was more or less undefined (i guess it was xxyyzz). It's better > to be consistent and always use urlencode. This is easily rollbacked > (it's two lines) and I'd really like to ear comments about this. have to check, but in general I'm a fan of consitency ;) > >> 2003.07.21 - made wap cookies enable per default. Please complain about > >> what is not working with them so I can fix it. So far, I know, and I'm > >> working thowards it, that we should try to send cookies to device > >> (bug 34), that cookies are not checked for domain, path and secure (bug > >> 64), and that they might not work at all with connectionless wap. > >> I need cookie support and I'd rather activate it and fix it. > > > > +1, we have to work on passing the Cookies in WSP encoding to the > > device. > > I'm first fixing cookie domain/path support and then I'll do this. ok. Stipe [EMAIL PROTECTED] ------------------------------------------------------------------- Wapme Systems AG Vogelsanger Weg 80 40470 D�sseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de ------------------------------------------------------------------- wapme.net - wherever you are
