Re: [reSIProcate] [reSIProcate-users] Bug report
Seems the reSIProcate 1.4.1 still not fixed this bug - I just test it a moment ago.
On Thu, Jul 24, 2008 at 11:24 PM, Robert Sparks
<rjsparks@xxxxxxxxxxxx> wrote:
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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/