My github repo has some code for parsing the .har files. In python and js
it is trivial (around 3 loc) to parse them. For my c++ code, I invoke
(fork) the python to parse them and then put them in simplified http/1
header format and pipe it into the c++ code.
-=R
On Oct 25, 2012 1:13 AM, "RUELLAN Herve" <Herve.Ruellan@crf.canon.fr> wrote:
> > -----Original Message-----
> > From: James M Snell [mailto:jasnell@gmail.com]
> > Sent: mercredi 24 octobre 2012 21:44
> > To: Mark Nottingham
> > Cc: Patrick McManus; Roberto Peon; Amos Jeffries; ietf-http-wg@w3.org
> > Subject: Re: HTTP Header Compaction Results
> >
> >
> >
> >
> > On Wed, Oct 24, 2012 at 12:39 PM, Mark Nottingham <mnot@mnot.net>
> > wrote:
> >
> >
> > On 25/10/2012, at 5:00 AM, Patrick McManus
> > <pmcmanus@mozilla.com> wrote:
> > >
> > > for reference https://developer.mozilla.org/en-
> > US/docs/NSS_Key_Log_Format
> >
> > Thanks; I looked for that before, but couldn't find it. Should have
> > asked.
> >
> > I agree that the logs should be 'raw'; we can always post-process
> (as
> > long as we do it in a uniform manner :)
> >
> > How would people prefer to store them? I've been storing them as
> > just text files, one per direction per stream (e.g., "response headers
> on this
> > connection to 1.2.3.4"), with header blocks delimited by a blank line.
> > However, IIRC someone mentioned HAR as well -- any preferences?
> >
> >
> >
> >
> > text files would work just fine.
>
> I agree that text files are OK.
>
> HAR could also work, but are somewhat more complex to process. Moreover I
> think it's easier to write a HAR to text files translator than the reverse.
>
> Hervé.
>
> > - James
> >
> >
> > Cheers,
> >
> >
> > --
> > Mark Nottingham http://www.mnot.net/
> >
> >
> >
> >
> >
> >
>
>