Going beyond performance on HAR

[rvelosoo]

Hello all,

Just wanted to kick off a discussion here about starting to include
errors in the HAR besides performance values. It seems the only
explicit way errors are encoded now are in the http response code or
in negative values in some performance fields. But this may not be
enough to detect errors since incomplete or broken tcp connections can
produce performance values, even though the receiving phase was not
completed. Would it make sense to include error fields in the HAR in
each stage along with the performance values? The fundamental problem
is that it doesnt make sense to measure performance of errors...

Cheers,

--Ricardo

[Pierre Moysan]

Le 27/06/2011 21:04, rvelosoo a �crit :

Thanks

[Romain]

Indeed, previously I hacked Netexport to make it show the errors.

My hack was to generate a RESPONSE with a status code = -1, when no response was received. 

In so doing, I was able to see which requests failed with har viewer.

So, I totally approve the idea of incuding errors directly in the HAR specification.

Cheers

Romain

2011/6/27 Pierre Moysan <pierre....@gmail.com>

[Pieter Ennes]

Hi,

Good topic.

What type or level of errors are we talking about? A problem I see
here is that things might go wrong in many different browsers and on
many different levels, such as DNS, socket, proxy and browser
internals. There is (to my knowledge) no standard to encapsulate all
these types of errors into a single code allowing for detailed
automated interpretation of the error in a viewer.

Unless we invent such a Uni(error)code standard and try to push it out
to all browser vendors, I'd guess the best possible interpretation
would be to check for a non-zero error code and display a free-form
message, if provided.

But I agree that having something like a secondary error code and
message in the spec would be a win, for the reason that any viewer is
then able to show it.

- Pieter

On Jun 28, 8:11 am, Romain <filir...@gmail.com> wrote:
> Indeed, previously I hacked Netexport to make it show the errors.
>
> My hack was to generate a RESPONSE with a status code = -1, when no response
> was received.
> In so doing, I was able to see which requests failed with har viewer.
>
> So, I totally approve the idea of incuding errors directly in the HAR
> specification.
>
> Cheers
>
> Romain
>

> 2011/6/27 Pierre Moysan <pierre.moysa...@gmail.com>

[Ricardo Oliveira]

Hello Pieter and all,

Yes, I think having a code in each step with a value that indicates error (-2?) might be enough to flag an error in the phase for each entry, and the free form text field would allow for entropy between browsers. Also, there can be errors hard to pinpoint to a specific phase, so maybe having an generic error flag+free form text field for each entry also makes sense? In the same lines, having a generic error flag + free text form at the page level might also make sense. Certainly cleaner than having an associated error field for each entry-phase pair..

Cheers,

--Ricardo