RE: [reSIProcate] bug with encoding extensionHeaders onPower_Macintosh
This has been fixed in rev 6079-see commit message for details. It has only
been tested on linux so far; try it on offending platforms.
--Derek
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bruce Lowekamp
> Sent: Monday, March 13, 2006 7:31 PM
> To: Dale R. Worley
> Cc: Resiprocate-devel
> Subject: Re: [reSIProcate] bug with encoding extensionHeaders
> onPower_Macintosh
>
> Took me awhile to get back to looking into this.
>
> I took a look at the code generated in Headers.cxx by the preprocessor
> and there's no difference between the two architectures in the
> assignment of all of the arrays at the end of the file, but I don't
> know whether they're modified anywhere else, of course.
>
> more comments inline
>
> On 3/8/06, Dale R. Worley <dworley@xxxxxxxxxxx> wrote:
> > On Wed, 2006-03-08 at 00:05 -0500, Bruce Lowekamp wrote:
> > > Hmm, I can probably track down why there is a difference between the
> > > platforms, but I'm not sure I believe it's valid. Given this BNF from
> > > 3261:
> > >
> > > extension-header = header-name HCOLON header-value
> > >
> > > and reading the beginning of 7.3:
> > >
> > > Specifically, any SIP
> > > header whose grammar is of the form
> > >
> > > header = "header-name" HCOLON header-value *(COMMA header-
> value)
> > >
> > > allows for combining header fields of the same name into a comma-
> > > separated list.
> > >
> > >
> > > it looks to me like extension-header's can't be COMMA separated.
> >
> > I think most people take the syntax of "extension-header" as being a
> > place-holder, a warning to implementors that additional headers must be
> > parsed, if only to be ignored.
> >
> > People will interpret 7.3 as applying to any additional header whose
> > official definition has the comma-delimited form.
> >
> > Which means that if resip changes its behavior for a header based on
> > whether 7.3 applies, it needs to know, for every header it sees, whether
> > to apply 7.3 or not.
> >
>
> I see this a bit differently. 7.3 is very specific that only headers
> of that form can be comma separated. I take the extension-header as a
> sort of "generate strictly" issue, where unless you know it's OK to do
> comma encoding, you don't do it. However, this really isn't the issue
> here, as my problem is that resip isn't doing the right thing
> regardless of whether it can or can't comma-encode it.
>
> > > Anyway, if it is legal syntax, then shouldn't resip be parsing them as
> > > separate headers so I can iterate over them properly? This is
> > > actually what caused me to start poking around at this. Right now my
> > > header reading code consists of two loops:
> > >
> > > iterate over header(h_Foos) {
> > > split on commas{
> > > process each piece
> > > }
> > > }
> > >
> > > It works fine, but it's a bit ugly.
> >
> > Do you have to do this for headers defined in 3261 for which 7.3
> > applies, such as Contact?
>
> Interestingly, I can't get Contact to be comma encoded with a test
> example, however, I did iterate through Allow: , which is comma
> encoded, and it iterates fine. I suppose this isn't really surprising
> since you can't return a comma separated token, but it still means
> that the extension header interface is giving an inconsistent
> interface to the way the others are handled. I don't think any of the
> StringCategory headers can be COMMA separated, actually. Which
> probably makes sense if they're allowed to have commas.
>
> Bruce
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel