Stipe Tolj <[EMAIL PROTECTED]> wrote: > Bruno Rodrigues wrote: >> >> 2003.07.07 - header packing implemented >> I've implemented this feature to aggregate similar headers because some >> devices I have sends so many headers that if we send one header per >> value, I get "too many headers", if I aggregate them all in one header, >> I get "header too long". >> http_header_pack packs headers with 256 characters (defineable) > > definetly +1. Even while we make a workarround for too tightly > confiured HTTP servers. We've seen these problems on various devices > too.
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. ;) >> 2003.07.13 - wbxml dynamic version byte and wap dynamic version byte >> I'm looking at device header sent and I'm setting wbxml version acordly. >> I'm looking at wml's externalid declaration and settings wbxml's wap >> version acordly. This was required because SE-T610 looks at them and >> would ignore some 1.3 tags if version was 1.1 - it won't respect >> <form type="multipart/form-data" for example > > so this fixed the 'multipart/form-data' thing for SE? 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. >> 2003.07.13 - preliminary support to decode mms binary into text. >> deconverter is implemented, I'm just waiting for Stipe's commits for his >> mms code. > > +1, it's coooooooooming. Let me have my hands on the configure/make > process and you will have a bunch of commits here. It's gonna be > anyway after 1.3.2 has been released. No problem to me. Code is commented and MMS in and out and multipart/mixed will be implemented only after 1.3.2 >> 2003.07.13 - removed "Version=0" parameter when sending cookies to >> external servers. This is not very explicit in specification but I >> haven't ever seen a client sending this parameter > > +0, ok with me. Anyway, $<name>=value parameters are ignored anyway, so my removal shouldn't make any change. >> 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... ;) >> 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. In my to-do queue there is a complete review of fakesms and http, so I'll later check out if both are working ok. >> 2003.07.20 - added hplmn and auth-code support, although not yet >> implemented on smsc_emi (bug #54) > > ?? (have to check mantis) These are only two more parameters which I've added to smsbox but forgot to add to smsc_emi2. bug 54 is to remember me to add it in there ;) >> 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. >> 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. >> 2003.07.23 - added new url-map groups (deprecating map-url directives) >> to enable, for each url, an rewriten url, a query-string parameter to >> send msisdn, an header to send msisdn, an msisdn format and if kannel >> accepts cookies or not. This is required for Telcos to enable msisdn >> sending and cookie support only to who they want to. > > should we have something like Apache mod_rewrite implemented here? map-url concept is enough for us, I guess. We shouldn't be doing complex rewritings in kannel (map prefixes should be enough in my opinion, dropping '*' requirement - http://foo.com/ -> http://bar.com is the most used cases in telcos. > Yeah, that's the old "I'm the telco and I have the power *prune*" > story ;)) "I don' trust external sites and I don't want to hold their cookies ;)" >> 2003.07.23 - added proxy-authorization support to kannel. In wap >> architecture, kannel IS the proxy, so those values are to be processed >> by kannel and not by and external server (kannel was already removing >> that header before requesting). with user-map groups, you can define an >> user/pass to msisdn map to be used before requesting radius. >> As we (and most of the people) don't have access to radius packets, this >> is a simple and easy way to add device identification and enable kannel >> to send msisdn headers, simulating other products. Too bad that some >> devices (Nokia) doesn't have proxy auth parameters :(( > > that's an religious issue. Kannel is not and HTTP proxy in direct > terms. It is responsible for WSP <-> HTTP proxying. Kannel *IS* a proxy. period. Just think about this: does it make any sense to have an external server replying with Proxy-Authorize to a device if you don't have proxy configuration parameters ?. Oh, wait, you have proxy configuration parameters - it's wapgw ip, user and password :P > Have to check this more deeply. > >> Things in my to-do queue: >> finish what's left to finish in previous list >> finish whatever is marked as /* DAVI: .... */ in code >> finish mms decoding/encoding as soon as Stipe commits his code >> other stuff marked on bugs.kannel.org > > ohhh, please addd this too: > * reformat all my commits to comply with CodingStyle rules *grrrrrr* > ;) (I really hate those <tab>s from you ;) <tab><tab><tab> sorry, I'm "man vi"'ing now.. better, after coffee :P > Good work so far Bruno! > > Stipe
