Just remark.
SX1 behavior _NOT_ conforms to wap specification, because besides general encoding there is well-known encoding for Accept header:
8.4.2.7 Accept field
The following rules are used to encode accept values.
Accept-value = Constrained-media | Accept-general-form
Accept-general-form = Value-length Media-range [Accept-parameters]
Media-range = (Well-known-media | Extension-Media) *(Parameter)
Accept-parameters = Q-token Q-value *(Accept-extension)
Accept-extension = Parameter
Constrained-media = Constrained-encoding
Well-known-media = Integer-value
; Both are encoded using values from Content Type Assignments table in Assigned Numbers
Q-token = <Octet 128> )
And we have: Accept-general-form => Value-length Media-range [Accept-parameters]
So value-length is 0 and Media-range (mandatory) is absent.
So Accept header must be either as string "Accept: ..." or "80 ..." and in the last case it _MUST_ be encoded as Accept-value.
Stipe Tolj wrote:
Paul P Komkoff Jr wrote:
Ok well, yes I know I was offline fot _too_ _long_. I can't promise I will not do the same again :)
Now, to the kannel. Guess what Siemens SX1 latest firmware sends in request headers? It sends an \0x80 \0x00! Of course kannel is unable to do anything useful, because Accept for application/...wmlc is below that line, so voila.
I don't know is this handset behavior conforms to wsp spec, or not (have no time to check yet). But anyway, we have plenty of these here,
and users report that they are aple to browse through our competitors.
Patch attached.
ok, confirming from Paul's sniffing dump he send me, that the Siemens SX1 sends in WSP hedaers, something like this:
[...] Accept: application/foobar Accept: Accept: vnd/foobar [...]
meaning for the middle line: 0x80 for Accept and 0x00 for <end-of-string>.
I just reviewed WAP-230-WSP-20010705a.pdf, section 8.4.2.7. According to 8.4.2.1 (basic rules) we have the following BNF style:
Extension-media = *TEXT End-of-string
; This encoding is used for media values, which have no well-known binary encoding
which means in my interpretation '*TEXT' can be any chain of characters with length 0-n. Right?
If yes, then the SX1 behaviour _IS_ protocol conform to WSP header encoding. And I would vote +1 for addopting this patch to a more generic form for those WSP header values that can be of type 'Extension-media' as defined by WSP specs.
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/ -------------------------------------------------------------------
-- Vjacheslav Chekushin mailto:[EMAIL PROTECTED] Latvian Mobile Phone Company http://www.lmt.lv
