Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Our HAR files don't load in the Chrome dev tools #45

Closed
baltpeter opened this issue May 14, 2024 · 4 comments
Closed

Our HAR files don't load in the Chrome dev tools #45

baltpeter opened this issue May 14, 2024 · 4 comments
Assignees

Comments

@baltpeter
Copy link
Member

While working on tweaselORG/docs.tweasel.org#7, I noticed that the HAR files we create (via mitmproxy's har_dump) don't load in Chrome.

Example HAR (renamed to .json, because GitHub doesn't allow .har uploads): be.stib.mivb.mobile.har.json

If I try to load that in the Chrome network tab, I get:

Failed to load HAR file with following error: Invalid date format

image

I am running: Chromium Version 123.0.6312.122 (Official Build) snap (64-bit)

@baltpeter
Copy link
Member Author

baltpeter commented May 14, 2024

Looks like the problem is in log.pages.

For us, this currently always looks like this:

{
   "pages": [
        {
            "pageTimings": {}
        }
    ]
}

Whereas Chrome actually fills it:

{
    "pages": [
      {
        "startedDateTime": "2024-05-14T05:58:18.075Z",
        "id": "page_1",
        "title": "https://spiegel.de/",
        "pageTimings": {
          "onContentLoad": 1034.15900003165,
          "onLoad": 1035.6270000338554
        }
      }
    ]
}

The problem appears to be the missing startedDateTime. If I manually add that, the HAR loads fine.

{
	"pages": [
        {
            "startedDateTime": "2024-05-14T05:58:18.075Z",
            "pageTimings": {}
        }
    ],
}

@baltpeter
Copy link
Member Author

This was fixed in mitmproxy 10 (we depend on v9): mitmproxy/mitmproxy#5814

Indeed, with just an empty pages array, it works in both Firefox and Chrome.

@baltpeter
Copy link
Member Author

Since mitmproxy 10.1 brings native HAR export anyway, I guess it makes most sense to defer this issue to #36.

@baltpeter baltpeter reopened this May 14, 2024
@baltpeter
Copy link
Member Author

I've changed my mind. This is quite an unfortunate problem and I would really rather not keep producing incorrect HAR files.

While I do indeed not have the time to properly test upgrading to a new mitmproxy version right now, this is easy enough to hotfix on our end.

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

No branches or pull requests

1 participant