[Bug 721764] New: souphttpsrc: [PATCH] Add ability to do HTTP session logging

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=721764
  GStreamer | gst-plugins-good | git

           Summary: souphttpsrc: [PATCH] Add ability to do HTTP session
                    logging
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: reynaldo at opendot.cl
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=265630)
 View: https://bugzilla.gnome.org/attachment.cgi?id=265630
 Review: https://bugzilla.gnome.org/review?bug=721764&attachment=265630

Add ability to do HTTP session logging

While working on another soup related issue I noticed
libsoup provides API facilities to do HTTP session logging.
As I have found myself in need of such a feature I figured
it wouldn't hurt to add this to our soup elements.

I'm initially proposing the following (quite preliminary) patch
to gather some feedback but if deemed useful I can move it
out of the src element and make it a .h/.c util-like set
for both soup elements to use.

The change basically adds an http-logging-level prop, if set
and > 0 it will instruct soup to dump HTTP request&response lines,
full headers and full body sections for levels 1,2 and 3
respectively. A session dump will be added to the normal
logs and looks like this (for a request/response lines (M) &
HEADERS (H) one):

 HTTP_SESSION(M): > GET /stream.webm HTTP/1.1
 HTTP_SESSION(M): > Soup-Debug-Timestamp: 1389145737
 HTTP_SESSION(M): > Soup-Debug: SoupSessionAsync 1 (0x18e9240), SoupMessage 1
(0x188d5c0), SoupSocket 1 (0x16d5640)
 HTTP_SESSION(H): > Host: xxx.mooo.com:8000
 HTTP_SESSION(H): > Connection: close
 HTTP_SESSION(H): > User-Agent: GStreamer souphttpsrc libsoup/2.44.1
 HTTP_SESSION(M):   
 HTTP_SESSION(M): < HTTP/1.0 200 OK
 HTTP_SESSION(M): < Soup-Debug-Timestamp: 1389145777
 HTTP_SESSION(M): < Soup-Debug: SoupMessage 1 (0x188d5c0)
 HTTP_SESSION(H): < Server: Icecast 2.3.99.3
 HTTP_SESSION(H): < Date: Wed, 08 Jan 2014 02:42:29 GMT
 HTTP_SESSION(H): < Content-Type: video/webm
 HTTP_SESSION(H): < Cache-Control: no-cache
 HTTP_SESSION(H): < Expires: Mon, 26 Jul 1997 05:00:00 GMT
 HTTP_SESSION(H): < Pragma: no-cache
 HTTP_SESSION(H): < icy-description: lolo
 HTTP_SESSION(H): < icy-name: lala
 HTTP_SESSION(H): < icy-pub: 0
 HTTP_SESSION(M):   
 HTTP_SESSION(M): > GET /stream.webm HTTP/1.1
 HTTP_SESSION(M): > Soup-Debug-Timestamp: 1389145778
 HTTP_SESSION(M): > Soup-Debug: SoupSessionAsync 1 (0x18e9240), SoupMessage 2
(0x188d6b0), SoupSocket 2 (0x16d5700)
 HTTP_SESSION(H): > Host: xxx.mooo.com:8000
 HTTP_SESSION(H): > Connection: close
 HTTP_SESSION(H): > Range: bytes=1662974-
 HTTP_SESSION(H): > User-Agent: GStreamer souphttpsrc libsoup/2.44.1
 HTTP_SESSION(M):   
 HTTP_SESSION(M): < HTTP/1.0 1 Cancelled
 HTTP_SESSION(M): < Soup-Debug-Timestamp: 1389145778
 HTTP_SESSION(M): < Soup-Debug: SoupMessage 2 (0x188d6b0)
 HTTP_SESSION(H): < Server: Icecast 2.3.99.3
 HTTP_SESSION(H): < Date: Wed, 08 Jan 2014 02:43:10 GMT
 HTTP_SESSION(H): < Content-Type: video/webm
 HTTP_SESSION(H): < Cache-Control: no-cache
 HTTP_SESSION(H): < Expires: Mon, 26 Jul 1997 05:00:00 GMT
 HTTP_SESSION(H): < Pragma: no-cache
 HTTP_SESSION(H): < icy-description: lolo
 HTTP_SESSION(H): < icy-name: lala
 HTTP_SESSION(H): < icy-pub: 0
 HTTP_SESSION(M):   

( < and > for inbound & outbound respectively)

Some questions:

Would a new log category be needed?
I'm using GST_DEBUG. If user goes GST_LOG_LEVEL < 4 these messages are going to
be ignored. Does this sound like an acceptable compromise?
What if the log subsystem gets disabled at build time, would it be OK
to add an ifdefed fallback to printf logging for the log printer callback?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.