Skip to content

feat(har): record sizes, compression and httpVersion#6695

Closed
tnolet wants to merge 15 commits intomicrosoft:masterfrom
checkly:har-tracer-update
Closed

feat(har): record sizes, compression and httpVersion#6695
tnolet wants to merge 15 commits intomicrosoft:masterfrom
checkly:har-tracer-update

Conversation

@tnolet
Copy link
Contributor

@tnolet tnolet commented May 21, 2021

This PR attempts to update a set of missing properties in the HAR file, where earlier a default -1 was reported and also report the correct HTTP Version, which was hard coded to HTTP/1.1

The test in tests/har.spec.ts:244 should show what is being done.

  • bodySize
  • headersSize
  • httpVersion
  • _transferSize: note this is not an official property, but used by Chrome.
  • content.size
  • content.compression

The biggest change is that the fields at the end of the request/response cycle are now done on Page.Events.onRequestFinished instead of Page.Events.onResponse.

Note 1

This does not work yet for Firefox as no transferSize like property is available. However, we can probably make that happen with some work on the NetworkObserver.js patches.

Note 2

I went down the rabbit hole of solving this problem by populating the various size using the performance.getEntriesByName() API from the browser. However, CORS settings makes this unreliable.

tnolet added 5 commits May 7, 2021 17:29
The http version was hard coded to http/1.1 which was wrong. Als h2 and h3 have different ways of
reporting headers and lenghts
HTTP version is now resolved in one place or substituted by a fallback. Works with reporting h2 and
later.
@ghost
Copy link

ghost commented May 21, 2021

CLA assistant check
All CLA requirements met.

@tnolet tnolet changed the title Har tracer update feat(har): sizes, compression and httpVersion May 21, 2021
@tnolet tnolet changed the title feat(har): sizes, compression and httpVersion feat(har): record sizes, compression and httpVersion May 21, 2021
@tnolet tnolet marked this pull request as ready for review June 4, 2021 16:52
Copy link
Contributor

@dgozman dgozman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall, left a few comments.

this._log.pages.push(pageEntry);
page.on(Page.Events.Request, (request: network.Request) => this._onRequest(page, request));
page.on(Page.Events.Response, (response: network.Response) => this._onResponse(page, response));
page.on(Page.Events.RequestFinished, (request: network.Request) => this._onRequestFinished(page, request));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not all requests finish, some of them stall, and others fail. I think we should update half of the fields on Response event, and another half on RequestFinished/RequestFailed. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, this is a correct observation. Somehow it is feels messy though. Reading the code it's not super clear what gets done when. I do think we have no other way, this is how HTTP / Browser networking is.

Testing this is tricky. We would need a local server for tests that does not respond or stalls some requests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can just add a test with a failed request and see that some information is there. I do not think that extra testing complexity will be worth it in this particular case.

postData: undefined,
postData: postDataForHar(request) || undefined,
headersSize: -1,
bodySize: -1,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aslushnikov
Copy link
Contributor

@tnolet
Copy link
Contributor Author

tnolet commented Jun 28, 2021

Hey @tnolet! What's the status of this?

For the firefox, it'll be very easy to export transfer size: https://ffsearch.azurewebsites.net/#path=%2Fhome%2Fjoe%2Fplaywright%2Fbrowser_patches%2Ffirefox%2Fcheckout%2Fnetwerk%2Fprotocol%2Fhttp%2FnsIHttpChannel.idl&line=90

I can help with this if needed!

@aslushnikov I think we are pretty damn far with this. It would be great if you can help patch FF so we can keep this PR simple and not make any exemptions for FF. How should we coordinate this? I see the following steps:

  • have FF export transferSizes
  • integrate the FF tranferSizes so they are available to the harTracer.
  • fix any merge conflicts
  • profit?

@mxschmitt
Copy link
Contributor

Closing since #7470 is merged.

@mxschmitt mxschmitt closed this Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants