Re: [reSIProcate] bug with encoding extensionHeaders on Power_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