Re: [reSIProcate] bug with encoding extensionHeaders onPower_Macintosh
I confirm that the bug was fixed in 6097 for Darwin.Power_Macintosh
I owe you a beer.
Bruce
On 3/21/06, Derek MacDonald <derek@xxxxxxxxxxxxxxx> wrote:
> 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
>
>