[reSIProcate] [reSIProcate-users] Bug report

[Robert Sparks]

For anyone that's trying to wrap their heads around this and having  
trouble:

Accept:

(That is an Accept: header with no values) in a message means  
something fundamentally different than a message with no Accept header  
field at all. It explicitly says this UA will Accept no MIME-types  
where the absence of the field means the UA is not telling what it  
will accept or not.

To answer Byron's question, though, I did a quick skim of the header  
fields defined in 3261 and don't see any where it makes sense for them  
to be present with no value. I can't, off the top of my head, think of  
any already defined elsewhere that would allow no value. And (with the  
caveat that I haven't thought about it very long) can't think of any  
really good reason anyone would _want_ to define a single valued  
header where no value meant something. The only thing I can come up  
with is if the header field is intended to carry some literal and the  
empty string is a valid literal in its context, but I would hope  
whoever defined it would put some delineators (or use some encoding)  
to reduce the potential ambiguity.

(If I ever get to influence some future protocol, I will argue against  
the form we're allowing for header fields like Accept and ask for  
explicit bits that can be put there to semantically signal "none").

RjS


On Jul 24, 2008, at 10:04 AM, Byron Campen wrote:

> 	Moving this to resip-devel:
>
> 	Hmm, it looks like we're tripping over the code that is meant to  
> distinguish "Accept: " from the absence of an Accept header (or  
> other headers of that type; Allow, Allow-Events, etc). These are all  
> multi-value headers.
>
> 	Should we really be doing this for single-value headers? I don't  
> think we should. If we get a single value header that is empty, we  
> should not be representing it as an empty list. Can anyone think of  
> a counter-example where an empty single-value header needs to be  
> fundamentally conceptually different than a normal single-value  
> header?
>
> Best regards,
> Byron Campen
>
>> Thank you Byron, but same problem, this is my code:
>>
>>         Data subject;
>>
>>         if (sub.exists(h_Subject)==true &&  
>> sub.header(h_Subject).isWellFormed()==true)
>>         {
>>             subject = sub.header(h_Subject).value();
>>         }
>>
>>
>> On Thu, Jul 24, 2008 at 10:42 PM, Byron Campen  
>> <bcampen at estacado.net> wrote:
>> 	You need to throw in a sub.header(h_Subject).isWellFormed() in  
>> that check, ie:
>>
>>>         Data subject;
>>>
>>>         if (sub.exists(h_Subject)==true &&  
>>> sub.header(h_Subject).isWellFormed() &&  
>>> sub.header(h_Subject).value().empty()==false)
>>>
>>>         {
>>>             subject = sub.header(h_Subject).value();
>>>         }
>>
>>
>> Best regards,
>> Byron Campen
>>
>>> Hi all, I think I found a bug:
>>>
>>> 1: I using the counterpath Bria to send a presence SUBSCRIBE to my  
>>> UA.
>>> 2: I use wireshark to capture the SUBSCRIBE message, saw it has  
>>> Subject header, but this header value is empty.
>>>
>>> 3: onNewSubscription(ServerSubscriptionHandle h, const SipMessage&  
>>> sub)  call back is fired, then I use this code to access the  
>>> Subject header:
>>>
>>>         Data subject;
>>>
>>>         if (sub.exists(h_Subject)==true &&  
>>> sub.header(h_Subject).value().empty()==false)
>>>         {
>>>             subject = sub.header(h_Subject).value();
>>>         }
>>>
>>> When running to sub.header(h_Subject).value().empty()==false, the  
>>> VC2005 debuger go to dialogusagemanager.cxx line 1778:
>>>
>>>             catch (BaseException& e)
>>>             {
>>>                SipMessage failure;   <----------- it's go to here
>>>                makeResponse(failure, request, 400, e.getMessage());
>>>                failure.header(h_AcceptLanguages) =  
>>> getMasterProfile()->getSupportedLanguages();
>>>                sendResponse(failure);
>>>             }
>>>
>>>
>>> If  the subject header value is not empty, then all are ok.
>>>
>>> thanks
>>> _______________________________________________
>>> resiprocate-users mailing list
>>> resiprocate-users at resiprocate.org
>>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080724/de1873b7/attachment.htm>