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.
Paul
Iñaki Baz Castillo wrote:
> Hi, RFC 3261 says:
>
> 8.2.2 Header Inspection
>
> If a UAS does not understand a header field in a request (that is,
> the header field is not defined in this specification or in any
> supported extension), the server MUST ignore that header field and
> continue processing the message. A UAS SHOULD ignore any malformed
> header fields that are not necessary for processing requests.
>
>
> But it doesn't explain what a malformed header is. Is it a header with a
> wrong
> value? For example, in the following case is there a malformed header and the
> UAS should ignore the header o isn't there a malformed header but a incorrect
> message syntax and the UAS should discard the entire message?
>
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
> From: <sip:[EMAIL PROTECTED];tag=qweqwe>
> To: <sip:[EMAIL PROTECTED]>
> Malforded Header ? : value
> Content-Length: 10
> CRLF
> <body>
>
>
> Thanks.
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
