[reSIProcate] From header valid?

[Robert Sparks]

Most of the time, you want the application to be able to decide just  
how much deviation it's going to allow.
Following Postel's Maxim, the stack is going to only get upset about  
bits that it has to have right to do its job.

Once you're up in your application, you'll be much happier if you  
only police the bits that are required to do your
job. (Rejecting a request because of a malformed header field that  
you aren't using as part of processing the request
doesn't help anybody).

RjS

On Nov 19, 2006, at 10:17 PM, Byron Campen wrote:

> 	In general, the parse code is not particularly picky. If the app
> wants to do additional validation of whether there are illegal
> characters in something, it can. There may be some value in
> implementing optional strict parse code, but it hasn't been done yet.
>
> Best regards,
> Byron Campen
>
>> Hello, thank you for your explanations, they are most valuable :-)
>>
>> Another question about the parser,
>> Does the parser verify if a name address is conform to RFC 3261 ?
>> for example I have this test that fails to recognize an invalid host
>> address :
>>
>> Data myString = "sip:user:password at do@@@.com:4242";
>> ParseBuffer pb(myString .data(), myString .size());
>> NameAddr address;
>> address.parse(pb);
>> Uri& uri = address.uri();
>> I get :
>> uri.scheme = "sip"
>> uri.user = "user"
>> uri.password = "password"
>> uri.host = "do@@@.com"
>> uri.port = 4242
>>
>> So the uri is parsed(/concidered valid ?), but the value
>> "do@@@.com" is
>> not a correct host name...
>> is it a bug or should I check by myself if each value is conform to
>> RFC?
>>
>> Thanks again to everyone for your precious help!
>>
>> Best regards
>> Julien
>>
>>
>>
>>
>>>     SipMessage::addHeader() is not intended to be used directly like
>>> that; this is the method that the pre-parser uses to add headers.
>>> Adding a header in this way carries a couple of special  
>>> consequences:
>>> first, the buffer specified by "value" is not owned by the header
>>> that
>>> is created, but it must persist for the lifetime of the SipMessage
>>> (the header is an overlay), and second, the parse of the header will
>>> not be carried out until something attempts to access it. The
>>> preferred method for adding a header to a SipMessage is something
>>> like
>>> the following:
>>>
>>> *snip*
>>> NameAddr from("sip:user at host.com");
>>> sipMessage.header(h_From)=from;
>>> *snip*
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>> Hello,
>>>> to add the header to the message I am doing :
>>>> message->addHeader(Headers::getType(name, nameLength), name,
>>>> nameLength, value, valueLength);
>>>> where name = "from" and value = "user at host.com"
>>>>
>>>> So this header should not be valid right?
>>>> I am thinking about adding  a test after addHeader to force the
>>>> parsing.
>>>> What do you think?
>>>>
>>>> Thanks for your help :-)
>>>> Julien
>>>>
>>>> Byron Campen a écrit :
>>>>>     You're probably tripping over the lazy-parser somehow. If this
>>>>> comes off the wire, it will not be parsed until you try to start
>>>>> accessing parts of it. Adding a parameter in this case will  
>>>>> trigger
>>>>> a parse, and the parse will fail. However, if you are creating  
>>>>> this
>>>>> NameAddr manually, how are you constructing it?
>>>>>
>>>>> Best regards,
>>>>> Byron Campen
>>>>>
>>>>>> Hello,
>>>>>> Sorry I have a small question, could one of you tell me,
>>>>>> if this is a valid from header?
>>>>>> From: user at host.com
>>>>>>
>>>>>> Sorry to ask that, resiprocate generates a parse error when I try
>>>>>> to add
>>>>>> the "tag=", (probably complaining about missing scheme)
>>>>>> but does not complain if I send a message as it is. (Why is  
>>>>>> that?)
>>>>>>
>>>>>> Thank you for your help
>>>>>>
>>>>>> --Julien Saito
>>>>>> ジュリアン　齋藤
>>>>>> julien at aplix.co.jp
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> resiprocate-devel mailing list
>>>>>> resiprocate-devel at list.sipfoundry.org
>>>>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --Julien Saito
>>>> ジュリアン　齋藤
>>>> julien at aplix.co.jp
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> -- 
>> Julien Saito
>> ジュリアン　齋藤
>> julien at aplix.co.jp
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel