Re: [reSIProcate] bug with encoding extensionHeaders on Power_Macintosh

["Bruce Lowekamp" <lowekamp@xxxxxxxxxxxxx>]

Jason,

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.

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.

There's a side point here that, while I believe the comma-separated
syntax isn't legal, I expect that to interoperate with other stacks,
sooner or later I would have to do the same code, anyway.  But that
isn't precisely the point.  Or maybe it is, I don't know.

Thanks,
Bruce


On 3/7/06, Jason Fischl <jason@xxxxxxxxxxxxxxx> wrote:
> Hi Bruce,
>
> On 3/6/06, Bruce Lowekamp <lowekamp@xxxxxxxxxxxxx> wrote:
> > I've discovered a processor-dependent issue with how resip is encoding
> > extension headers when there are multiple fields of the same extension
> > header name (e.g.:
> >
> >     m->header(h_Foos).push_back(resip::StringCategory("<first@header>"));
> >     m->header(h_Foos).push_back(resip::StringCategory("<second@header>"));
> >
> > on Darwin.i386 will result in the (proper, as I understand 3261) one
> > header per line in the outgoing message:
> >
> > FooID: <first@header>
> > FooID: <second@header>
> >
> > but on Darwin.Power_Macintosh, the same code produces a (illegal, I
> > think) comma, separated header:
> >
> > FooID: <first@header>, <second@header>
>
> This is actually valid as per 3261 grammar. It is a compile-time
> switch. I'm not sure why the mac code is behaving differently but it
> shouldn't really matter to any sip stack.
>
> Jason
>