Codecov Report

Attention: Patch coverage is 96.89922% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 82.87%. Comparing base (784ce30) to head (300f5b9).

@@            Coverage Diff             @@
##           master   #10839      +/-   ##
==========================================
+ Coverage   82.83%   82.87%   +0.04%     
==========================================
  Files         913      921       +8     
  Lines      246847   246975     +128     
==========================================
+ Hits       204474   204679     +205     
+ Misses      42373    42296      -77     

I'm looking at RFC3261 and some of the keywords being added like:

• Content-Type
• Content-Length
  also have "compact forms (l and c respectively).

I don't know how prevalent the compact form usage is; should your additions handle both forms of the headers iff the header has a compact form?

I'm looking at RFC3261 and some of the keywords being added like:

* `Content-Type`

* `Content-Length`
  also have "compact forms (`l` and `c` respectively).

I don't know how prevalent the compact form usage is; should your additions handle both forms of the headers iff the header has a compact form?

Definitely, those compact form must be handled.

Why not a generic sip.request_header keyword ? whose buffer would be name+value like http.request_header (and same for response)

Why not a generic sip.request_header keyword ? whose buffer would be name+value like http.request_header (and same for response)

I'm not sure I like that to be honest.
@victorjulien, thoughts?

Why not a generic sip.request_header keyword ? whose buffer would be name+value like http.request_header (and same for response)

I'm not sure I like that to be honest. @victorjulien, thoughts?

Why do not you like it ?
It would allow more signatures expressivity (not restricted to the headers added here), with less lines of code...

Why not a generic sip.request_header keyword ? whose buffer would be name+value like http.request_header (and same for response)

I'm not sure I like that to be honest. @victorjulien, thoughts?

Why do not you like it ? It would allow more signatures expressivity (not restricted to the headers added here), with less lines of code...

It's an important keyword for http. In general, the other http keywords like http.header_names, http.start, etc should probably all be recreated here. Rule writers love them :)

It's an important keyword for http. In general, the other http keywords like http.header_names, http.start, etc should probably all be recreated here. Rule writers love them :)

So, could I add a keyword as @catenacyber suggested in another PR, and leave this one as is once the compact form issue is resolved?

It's an important keyword for http. In general, the other http keywords like http.header_names, http.start, etc should probably all be recreated here. Rule writers love them :)

So, could I add a keyword as @catenacyber suggested in another PR, and leave this one as is once the compact form issue is resolved?

I'm ok with doing them in follow up PRs. Btw I suggest a more comprehensive list :)

It's an important keyword for http. In general, the other http keywords like http.header_names, http.start, etc should probably all be recreated here. Rule writers love them :)

So, could I add a keyword as @catenacyber suggested in another PR, and leave this one as is once the compact form issue is resolved?

I'm ok with doing them in follow up PRs. Btw I suggest a more comprehensive list :)

Sure, it's just a starting point :)

Replaced with #10907