[sr-dev] [kamailio/kamailio] pv: fixed error "pv_get_method(): no CSEQ header" (#2761)

[sergey-safarov]

#### Pre-Submission Checklist
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)

#### Type Of Change
- [x] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)

#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)

#### Description
pv: fixed error "pv_get_method(): no CSEQ header"
when sent HTTP request like
```
HTTP/1.1 200 OK
Sia: SIP/2.0/TCP 8.8.8.8:39813
Content-Type: application/json
Server: kamailio
Content-Length: 49

{"data":{"status-code":200,"reason-phrase":"OK"}}
```
You can view, comment on, or merge this pull request online at:

https://github.com/kamailio/kamailio/pull/2761

-- Commit Summary --

* pv: fixed error "pv_get_method(): no CSEQ header"

-- File Changes --

M src/modules/pv/pv_core.c (6)

-- Patch Links --

https://github.com/kamailio/kamailio/pull/2761.patch
https://github.com/kamailio/kamailio/pull/2761.diff

[Daniel-Constantin Mierla]

The example you provided is not an HTTP request, but an HTTP reply and it does not have a method in the first line. HTTP methods are GET, POST, PUT, ... Probably it should return $null for HTTP replies.

[sergey-safarov]

yes, Daniel
I have observed error `pv: fixed error "pv_get_method(): no CSEQ header"` with HTTP replies when trying to use
```
event_route[siptrace:msg]
{
if($rm =~ "OPTIONS|HTTP") {
xlog("L_DEBUG", "trace|dropping trace for method $rm\n");
drop();
}
}
```
My goal to avoid sending message copies via siptrace module for OPTIONS and for HTTP requests/responses.
Could you suggest which correct approach to solve this?

[sergey-safarov]

@sergey-safarov pushed 1 commit.

2579bdf52816d05858ead275882ff2d2de167556 pv: pv_get_method fixed error "pv_get_method(): no CSEQ header"

[sergey-safarov]

maybe implement functions in core
1. `is_request("HTTP")`
2. `is_request("SIP")`
3. `is_reply("HTTP")`
4. `is_reply("SIP")`

and move these functions from `siputils` to `core`
1. `is_request()`
2. `is_reply()`

[Daniel-Constantin Mierla]

Normally the HTTP traffic comes in event_route (or xmlrpc route). The core itself does not handle http, it can delegate processing to xhttp or xmlrpc modules, when configure to be _flexible_ on accepting non-sip traffic.

I think the is_reply()/is_request() should stay as they are specific to sip and eventually add is_http_request()/is_http_reply() can be added to xhttp module.

[sergey-safarov]

Think this PR ready to merge.

For `is_http_request()/is_http_reply()` i will create new PR.

[Daniel-Constantin Mierla]

Merged #2761 into master.