Biot Olivier <Olivier.Biot@xxxxxxxxxxx> - Mon, Nov 17, 2003:
> No problems with that, but some handsets do not always comply with this
> rule, so maybe we want to fall-back to text-string afterwards? Additionally,
> some handsets only display the starting quote, other handsets also encode
> the closing quote. And others don't quote at all :)
In my implementation, I've got a generic header name parser and a
generic header value parser used in cases where the guessed parser
fails. In this case (I've never met), the QuotedString parser would
fail and the HeaderValue generic parser will attempt to decode the
value as a stringz. This is based on section 8.4.1.2 which I've always
seen respected.
I see two possibilities to support nicely quoted-strings:
- we always parse the headers with a generic header-name + header-value
parser and put that in a tvb, then we try to call a specific parser on
this tvb;
- we try to guess the correct parser, with respect for the norm, and if
this fails, we fall back on a generic parser.
Right now, I think the main loop does something like trying to call the
parser from a table of macro generated parsers.
What do you think?
> | - what is this for:
> | "val_len++; /* For extra '\0' byte */"
> | ... also in packet-wsp.c, about line 1740 after this patch
> If the text string is { 'a', 'b', 'c', '\0' }, then val_len will only return
> 3 while the value is indeed encoded as 4 bytes (val_len is the actual length
> of the value as found in the packet). So we need to add this zero byte to
> the count.
That was understood, sorry for being unclear, I was wondering where do
you use your computed val_len? Maybe I'm misunderstanding some macro
stuff or this statement is "just in case", but it seems to me val_len
isn't used after this if {}.
--
Loïc Minier <lool@xxxxxxxx>
