HTTP traffic listener/sniffer

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

HTTP traffic listener/sniffer

Vic-6
Hi,

I'm looking for a way to log all network traffic at the http level,
including the messages buffers. Also I need to be able to link between the
sniffed HTTP conversation to the corresponding HTMLDocument in the web
browser.

I've found that logging is being made in nsHttpTransaction.cpp::Init(...)
and nsHttpTransaction::HandleContentStart() but it does not include the
messages buffers.

At both location, I can read the messages buffers using the stream interface
but when I do, the stream position gets lost and the process gets hang. I
can't restore the stream position back to were it was because this
functionality is not available with the given stream interface.

Every solution or idea will be appreciated.

Thanks,
Vic.


_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

Re: HTTP traffic listener/sniffer

Neil Stansbury-2
Not sure how much help this will be but...

Have a look at the httpheaders extension, it can intercept all HTTP
traffic including headers.

Regarding the hung process, I experienced the same with
nsIFileInputStream, I noticed that if fileStream.CLOSE_ON_EOF is set
then you cant get the stream, it's needs to be
nsIFileInputStream.REOPEN_ON_REWIND to intercept the stream itself.

N


Vic wrote:

> Hi,
>
> I'm looking for a way to log all network traffic at the http level,
> including the messages buffers. Also I need to be able to link between the
> sniffed HTTP conversation to the corresponding HTMLDocument in the web
> browser.
>
> I've found that logging is being made in nsHttpTransaction.cpp::Init(...)
> and nsHttpTransaction::HandleContentStart() but it does not include the
> messages buffers.
>
> At both location, I can read the messages buffers using the stream interface
> but when I do, the stream position gets lost and the process gets hang. I
> can't restore the stream position back to were it was because this
> functionality is not available with the given stream interface.
>
> Every solution or idea will be appreciated.
>
> Thanks,
> Vic.
>
>
_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

Re: HTTP traffic listener/sniffer

Vic-6
Thank you very much for you reply.

I can copy the headers and it works fine however the body of the message,
which is kept in a stream, is what I can't seem to grab without causing the
navigation to hang.
Anyhow, I believe your suggestion of using an HTTP Headers extension is
probably the right way to approach this issue rather then digging inside the
http network layer.

Any idea how can I grab the messages body buffer?

Thanks again,
Vic.


"Neil Stansbury" <[hidden email]> wrote in
message news:do4plg$[hidden email]...

> Not sure how much help this will be but...
>
> Have a look at the httpheaders extension, it can intercept all HTTP
> traffic including headers.
>
> Regarding the hung process, I experienced the same with
> nsIFileInputStream, I noticed that if fileStream.CLOSE_ON_EOF is set
> then you cant get the stream, it's needs to be
> nsIFileInputStream.REOPEN_ON_REWIND to intercept the stream itself.
>
> N
>
>
> Vic wrote:
> > Hi,
> >
> > I'm looking for a way to log all network traffic at the http level,
> > including the messages buffers. Also I need to be able to link between
the
> > sniffed HTTP conversation to the corresponding HTMLDocument in the web
> > browser.
> >
> > I've found that logging is being made in
nsHttpTransaction.cpp::Init(...)
> > and nsHttpTransaction::HandleContentStart() but it does not include the
> > messages buffers.
> >
> > At both location, I can read the messages buffers using the stream
interface
> > but when I do, the stream position gets lost and the process gets hang.
I
> > can't restore the stream position back to were it was because this
> > functionality is not available with the given stream interface.
> >
> > Every solution or idea will be appreciated.
> >
> > Thanks,
> > Vic.
> >
> >


_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

RE: HTTP traffic listener/sniffer

Andrei GACEFF
In reply to this post by Vic-6

Have a look at the function:

nsHttpTransaction::HandleContent(char *buf,
                                 PRUint32 count,
                                 PRUint32 *contentRead,
                                 PRUint32 *contentRemaining)


The <buf> variable points to a chunk of data of <count> bytes.
You can read the data inside <buf> with no fear that anything gets messed-up.

Be aware of the fact that <buf> does not contain Http transaction headers,
but (typically) file (Resource, as in URL) data.

To get data from headers, access nsHttpResponseHead instances.


I hope this info helps.

_______________________________________________
Mozilla-netlib mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-netlib
Reply | Threaded
Open this post in threaded view
|

Re: HTTP traffic listener/sniffer

Christian Biesinger
In reply to this post by Vic-6
Vic wrote:
> I'm looking for a way to log all network traffic at the http level,
> including the messages buffers. Also I need to be able to link between the
> sniffed HTTP conversation to the corresponding HTMLDocument in the web
> browser.

I'd suggest using http-on-modify-request to intercept HTTP requests
before they are sent to the server. You can QI the channel to
nsIUploadChannel and get the stream, and after reading it you can QI the
stream to nsISeekableStream and rewind it to position 0.


Linking channels to the corresponding HTMLDocument is hard, though... if
something that's not at all guaranteed to continue working in newer
versions is sufficient to you, you can get the load group's notification
callbacks, which are the docshell corresponding to the caller's
document. This is an implementation detail, though, and may thus change.


smime.p7s (6K) Download Attachment