Can we have multiple "To" header in any SIP request/response?
In rfc3261, defining SIP, multiple To headers are not allowed.
The interesting part is from Section 7.3 Header Fields
SIP header fields are similar to HTTP header fields in both syntax
and semantics. In particular, SIP header fields follow the [H4.2]
definitions of syntax for the message-header and the rules for
extending header fields over multiple lines. However, the latter is
specified in HTTP with implicit whitespace and folding. This
specification conforms to RFC 2234 [10] and uses only explicit
whitespace and folding as an integral part of the grammar.
[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)
Because the To header Augmented BNF does not contains COMMA, it means To can only be added once:
To = ( "To" / "t" ) HCOLON ( name-addr
/ addr-spec ) *( SEMI to-param )
The full Augmented BNF, which describe the rules, is available in Section 25
Related
I'm trying to sign email messages according to DKIM specification. I'm reading RFC 6376 and see there relatively straight way to create the signature, but there is a problematic part about DKIM-Signature header's tag b.
As I understand, it's value should be a base64 encoded signature of a hash, that is calculated against selected message headers, including DKIM-Signature, but without a value of the tag b. If it's correct, then I have some trouble understanding RFC here:
The header field MUST be presented to the hash algorithm after the
body of the message rather than with the rest of the header fields
Here the RFC speaks about DKIM-Signature header. The text is from the chapter "3.7. Computing the Message Hashes".
If I understand it correctly, then it means I must calculate a hash of a block, which includes full message body, with the DKIM-Signature header appended to it's end (variant 1). But as I read in other sources, including answers here, it seems (because there's no clear algorithm in other sources) that DKIM-Signature header should be appended to the end of a list of message headers, that are selected for the hashing (variant 2). Then the ambiguity is: which variant is correct?
And finally, after 2 hashes are calculated, should I sign the second hash (hash of headers after disambiguation of a correct variant), as it seems things should work, or should I sign just the list of selected (and canonicalized) headers?
A common sense tells me that variant 2 should be the actual choice, and signature should be applied to the second hash, but I'm in doubts.
The pseudo-code for the signature algorithm in RFC 6376 is wrong. It was corrected in Errata 5252:
body-hash = hash-alg (canon-body, l-param)
data-hash = hash-alg (h-headers, D-SIG)
signature = sig-alg (d-domain, selector, data-hash)
What it means is that you first hash the canonicalized message body up to the length specified in the l parameter and then include this hash in the bh tag of the DKIM-Signature header field. Afterwards, you start a new hash with the header fields as specified in the h tag and canonicalized according to the c tag (an empty string is included for non-existent header fields, so that adding these header fields later on invalidates the DKIM signature) followed by the DKIM-Signature header field which you are about to add without the b tag. The resulting hash is the one you sign. This means that your second variant is the correct one.
I want to parse JUST SIP Custom Headers [ or call attached data ] not
other header fields.
As I see some guys use "X-" to distinguish those headers from standard headers.
But that is just convention.
In some systems , attached-data [ custom-headers ] are put into just after "Content-Length: " header but some put it after "Contact: " header.
I really can not find a generic AND elegant way, just to parse custom headers.
The only bad solution is create a Look-Up Table which contains all standard sip headers names and if header name is not in that list, parse that header which is ugly...
Any suggestion for more elegant solution ?
It depends on what you want to accomplish, but since servers/clients/proxy can inject any header they want, your only solution really is to have a white-list of valid header names. The major down-side is you have to take care of any new RFCs that define new "official" headers.
Depending on the use-case, you might want to just go for headers starting with X-. As you said, it's just a convention, but it's one that in wide use, IIRC.
RFC 4180 talks about the text/csv mime type, but doesn't go into some of the more obvious variations that one would have to support, for example the separator used (ok ok so if it's Csv then it should obviously be a comma) and whether there is a header row or not.
I'd like to add parameters like separator=, and headerrow=0|1 to the mime type such that REST APIs that consume CSV files can consume them appropriately.
The alternative would seem to be to add the parameters to the URL but that feels wrong.
I've read through RFC 2617 and can't find there or anywhere else what the delimiter is if multiple schemes are supported. For example, suppose both Basic and Digest are supported. I understand that it may appear this way:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic
WWW-Authenticate: Digest
But I've also read that both can be listed as one line, but no one ever shows an example or describes what delimiter to use. I've seen cautions that commas can be used within a single scheme:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest param1="foo", param2="bar"
I've also read that if commas are used within a scheme, that other schemes must be placed on separate lines. So I imagine in the above case if we added Basic it would appear like this:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest param1="foo", param2="bar"
WWW-Authenticate: Basic
That's simple enough. But now suppose you just have one line
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Scheme stuff, morestuff, more stuff
Which is that? Is that a comma-delimited list of schemes, or is that one scheme, with a few parameters?
As far as I can tell, the spec punts on the issue. Section 1.2 states:
Note: User agents will need to take special care in parsing the WWW-
Authenticate or Proxy-Authenticate header field value if it contains
more than one challenge, or if more than one WWW-Authenticate header
field is provided, since the contents of a challenge may itself
contain a comma-separated list of authentication parameters.
I think we can translate special care to best of luck chap.
Pragmatism
As a practical matter, I suspect multiple schemes means one should use multiple wwww-authenticate headers. Schemes are extensible; e.g., I can come up with a scheme called "strawberry" or "opaque" if I want to be sinister. Given this, there isn't really a good way to parse a one liner without some sort of 'scheme termination' delimiter.
W3C Discussion
You aren't the first person with this question. There was a discussion on the W3C mailing list. The poster stated :
I wasn't questioning the need to provide multiple challenges in a
single response. I was only questioning the wisdom in allowing
multiple challenges in a single header field, given the odd
combination of separators it creates.
Some other threads discussing current issues & future action that may be of interest:
root of above thread
Backwards definition of authentication header
#342 WWW-Authenticate ABNF slightly ambiguous
WWW-Authenticate ABNF is ambiguous
future http 2 - Multi-legged Authentication for HTTP Multiplexing
If only ...
Not that I have the stomach for it, but one could dig through the chromimum, firefox & webkit code to see how those communities have handled the issue.
I'm working with a web application that sends some non-standard HTTP headers in its response to a login request. The header in question is:
SSO_STATUS: LoginFailed
I tried to extract it with LWP::Response as $response->header('SSO_STATUS') but it does not work. It does work for standard headers such as Set-Cookie, Expires etc.
Is there a way to work with the raw headers?
if you see the documentation of HTTP::Headers, it states that
The header field name spelling is normally canonicalized
including the '_' to '-' translation. There are some application where
this is not appropriate. Prefixing field names with ':' allow you to
force a specific spelling. For example if you really want a header field
name to show up as foo_bar instead of "Foo-Bar", you might set it like
this:
$h->header(":foo_bar" => 1);
These field names are returned with the ':' intact for
$h->header_field_names and the $h->scan callback, but the colons do
not show in $h->as_string.
See this thread on Perlmonks.
You need to access the value of the header field as $response->header('SSO-STATUS').
The syntax for setting fields with underscores in names:
$response->header(':SSO_STATUS' => 'foo');