Multiple headers with the same name should be allowed

[benlangfeld]

Tagging @bklang, @jsgoecke

The tricky point here is how we deal with headers on subsequent events.

eg:

<offer>
  <header name='foo' value='bar' />
</offer>

<end>
  <header name='foo' value='baz' />
</end>

Should this be considered as an additional value, or a replacement?

[bklang]

Adding my comment from #42:

In section 6.2.1 as well as other places, we allow setting arbitrary headers. What if the underlying telephony protocol allows multiple headers with the same name? I think the specification should address this in a couple of places:

1. Specifically allow for multiple headers with the same name.
2. Make some promise about the order of the headers being preserved at least as far as the delivery to the backend telephony protocol. I know that promising the same order in the SIP headers would be leaking SIP details into Rayo, but we should probably at least make some effort to guarantee order here (assuming order is ever significant).

From RFC 3261

[H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. 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. The Contact header field allows a comma-separated list unless the header field value is "*".

and

The relative order of header fields with different field names is not significant. However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.

[benlangfeld]

@loopingrage Any thoughts on how subsequently delivered values should be specified (replacement vs extra element in a collection)?

[bklang]

I feel pretty strongly that we need to support multiple headers with the same key/name and ensure that order is respected when handing it to the backend for processing.

On the client (Adhearsion) side we should consider the comma-delimited format recommended by the RFC, but both styles are considered valid by my reading.

[benlangfeld]

@bklang I want to stay away from the comma delimited thing, simply because it's SIP specific, but we do not specify the format of header values anyway so it's perfectly permissible. I also agree that we should support multiple headers of the same name. The only question is what it means in the example in the OP. Thoughts?

[bklang]

I'm not sure how Rayo deals with headers now. Two possible scenarios:

1) Headers are set and used only on the specific command. If a header is set for the <dial/> it should not be sent again on <end/> unless explicitly requested (this is my preference)

2) If headers are preserved then there should be a way to remove a specific header by providing it's key/value pair -or- removing all of a certain header by specifying only its key. If further headers are requested, they are additive.

I strongly prefer 1 since 2 seems confusing and error-prone.

[loopingrage]

Yea, option #1 for sure. I'm pretty sure that the RFC requires that we support both the comma separated approach AND the duplicate name approach. I don't think the server support duplicates since we're using a Map to store the headers. This is a bug and should be fixed in Rayo Server.