Questions about data deserialization

[Ooo0xffooO]

Hello, I recently encountered a data packet with a very large response, so httptoolkit kept loading it. I'm not sure if it's a problem with my computer or the tool, as I can deserialize it normally with other tools.

[Ooo0xffooO]

I can provide the HAR file if needed.
https://gofile.io/d/DBHJPh

[pimterry]

I've taken a quick look at the HAR. It seems that the headers mark this data as HTML (which is wrong - it's JSON) and the HTML formatter then gets stuck in an infinite loop somehow trying to format this data (I suspect it's run into some encoding edge cases somewhere, as there's a lot of unicode in here). For large bodies like this, formatting happens on a background queue to avoid blocking the UI, but this means that every other type of non-trivial formatting is then blocked by this infinite loop processing the HTML, which is why JSON doesn't load either.

You should find it's readable if you pick the 'Text' option though, which does basically zero formatting (just processes & renders it all as UTF8).

I'll take a look into this anyway though, we could definitely handle this better, both by not failing to format the HTML in the first place, and by using timeouts to stop infinite loops like this from blocking the formatting queue.

[Ooo0xffooO]

我快速查看了一下 HAR 文件。看起来它的头部信息将这些数据标记为 HTML（这是错误的，它实际上是 JSON），然后 HTML 格式化程序陷入了无限循环，试图格式化这些数据（我怀疑它在某些地方遇到了编码方面的特殊情况，因为里面有很多 Unicode 字符）。对于像这样的大型数据体，格式化操作会在后台队列中进行，以避免阻塞用户界面，但这也就意味着所有其他类型的复杂格式化操作都会被这个处理 HTML 的无限循环阻塞，这也是为什么 JSON 数据也无法加载的原因。

不过，如果您选择“文本”选项，应该会发现它是可读的，该选项基本上不进行任何格式设置（只是将所有内容处理并渲染为 UTF-8）。

不过我还是会调查一下这个问题，我们肯定可以处理得更好，既可以从一开始就正确格式化 HTML，也可以使用超时机制来防止像这样的无限循环阻塞格式化队列。

Thank you for your reply. Yes, it does contain some Chinese. Have a good day at work.

[pimterry]

I've just pushed a fix for this:

• Make the content type detection more confident: if it knows what the content is, it now overrides the content-type header to show the best-guess format by default. In this case that means it detects & formats as JSON automatically, not HTML.
• Optimized the JSON formatter, so it takes a much faster path for large valid JSON cases like this, so the content renders in about a second or so. Previously we used a custom relaxed JSON formatter by default - this is nice so that you can view invalid JSON (e.g. comments or trailing commas) but we don't need it most of the time and it's approximately 1000x slower on larger JSON inputs like this.
• Updating the HTML formatter dependency, which means it now completes much faster even in cases like this, and doesn't get stuck in an infinite loop (still takes a while but more like 10s, not minutes).

Thanks for reporting this, that's a nice little UX boost there. The app will update in the background next time you start it, and you'll see the fixes the following run. I'll close this, but let me know if you run into any more issues.