Re: [PATCH] Siemens SX1 kludge

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