[Bug 757118] rtspconnection: Problem when parsing vendor specific RTSP response with data after Content-Length

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757118

--- Comment #9 from Davy <realbrightster at gmail.com> ---
Hum..our perspective seem to little difference. may be my view is narrow then
your view.
Could you define range of "parser"?

Please consider that my brain doesn't support multi-core. it can process only
one task at single time and now all interrupts are disabled T_T..
after finishing read_line() problem, let me handle the other case.

My lat patch focus on "read_line()" only.
and it's about parsing message which not contain READ_AHEAD_EOH characters.

Firstly, we need to remind this issue again.

1. parsing "framerate: 30\r\n"

*2*. read_ahead stay in READ_AHEAD_CRLF because there is no more characters to
transit READ_AHEAD_EOH state or end of line. 
\r or \n -> can progress to next state (READ_AHEAD_CRLFCR or READ_AHEAD_EOH)
other char -> end of line.

at this time, all message was received but read_line() couldn't detect EOH so
it expecting next character.

3. receive next RTSP message for new keep-alive request: "RTSP/1.0 200 OK\r\n"
read_line() thinks.. wow we got the 'T'. finally we made one line hehe..
build_next() parse with only 'R' character.

4. GST_RTSP_EPARSE returned and rtspsrc send event EOS -> stop the pipeline.

So I think the root cause is detecting End Of Header.
Current scheme \r\n(Request line or Response Status-Line)  + \r\n (Ending
request, response header) is cool. it perfect meet to RFC 2326.

But another absolute condition is poll timeout when read socket buffer.
that's why I add below line:

      if (G_UNLIKELY (res != GST_RTSP_OK)) {
        /* could not reach final state but there is no more data. reset to
initial state. */
        if (GST_RTSP_ETIMEOUT == res)
          conn->read_ahead = 0;

        return res;
      }

You may curios why zero instead of READ_AHEAD_EOH and why return error
value(GST_RTSP_ETIMEOUT) not a GST_RTSP_OK?

yes, logically READ_AHEAD_EOH is better but build_next() is not thinks so.
It silently ignore error in read_line() and parse_line() but dose not allow
error in first line (parse_response_status, parse_request_line)
and I don't want that sending EOS event from rtspsrc to pipeline. that's all.

You may know about the reason of g_socket_get_available_bytes() addition.

- My brain ready to load next scheduled task. -

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.