El Wednesday 26 March 2008 14:18:58 Paul Kyzivat escribió: > AFAIK this is not well defined. I believe it must mean one that has > invalid syntax. But of course the syntax can't be so messed up that the > remainder of the message can't be parsed. > > Loosely I guess I would say that if it starts to match a known header > but fails in some way, yet can be parsed as an extension header, then > you should proceed on that basis, treating it as an unknown header. > > You could go beyond that, but the ABNF gives no guidance on how. This is > much like the recovery a parser for a programming language goes through > so that it may continue to provide diagnostics beyond an error rather > than simply giving up at the first error. > > One thing that is tricky, and which I don't think is done much, is to > generate a useful response to a malformed request. This can require you > to generate a response that is itself malformed.
Thanks a lot. In the parser I'm doing I allow known but incorrect headers if they are not neccesary (wrong value syntax in Authoriation...). But if I receive a malformed header field name or hte abscense of ":" I drop the entire message. I assume that is not very common to receive "headers" like: custom header : XXXXXX <-- invalid because space in the header name. CustomHeader asdasdasd <-- invalid because no ":" Hope it's enough. Thanks a lot. -- Iñaki Baz Castillo [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
