Re: HTTP Header Compaction Results

+1 on the timestamp.. it also gives some idea of data rate which can be
useful for calculating cpu budgets.
And if you're going to give meta data we can include a header length
instead of the blank line. (hey, where have I heard that discussion before?
:))

-P


On Thu, Oct 25, 2012 at 6:05 AM, Mark Nottingham <mnot@mnot.net> wrote:

> The only thing that gives me pause about using plain text is that if we
> want to combine streams to the same server to simulate multiplexing, we may
> want to apply a time-based heuristic to do so, meaning we'll need some
> metadata.
>
> Date is in responses, but not requests; I *guess* we could infer it from
> the paired responses, but then there's clock skew, etc.
>
> Just a thought; I'm happy with text if that doesn't worry anyone else.
>
> Cheers,
>
>
> On 25/10/2012, at 8:52 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> > On 25/10/2012 9:13 p.m., RUELLAN Herve 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.
> >
> > Since the traffic is arriving in HTTP text format to produce a HAR file
> one needs to write such a translator and apply it on the data stream.
> Producing a .txt can be just a packet buffer dump.
> >
> > Amos
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>