https://github.com/ahmadnassri/har-spec/blob/master/versions/1.3.md specifies some key fixes to HAR needed if one is dealing with binary APIs - e.g. GRPC.

Would be lovely to have that supported. What do you think?

error: invalid type: floating point 264.50300000033167, expected i64 at line 1 column 1

har file:

"time":` 264.50300000033167,

error: Error(
    Yaml(
        Message(
            "invalid type: floating point `264.50300000033167`, expected i64",
            Some(
                Pos {
                    marker: Marker {
                        index: 0,
                        line: 1,
                        col: 0,
                    },
                    path: ".",
                },
            ),
        ),
    ),
    State {
        next_error: None,
        backtrace: InternalBacktrace {
            backtrace: None,
        },
    },
)

• I noticed that some fields populated by Charles Proxy (version 4.6.1 for certain) are set to null. These files include:
• response.redirectURL
• content.mimeType
• Changing these fields to Option<String> improves compatibility with default Charles Proxy output.

Hi there,

Nice crate, thanks for writing! I'm just picking it up for a project of mine but I'm unsure about one thing. What's the meaning of the charles_status field on Response? I'm assuming this is related to Charles - it feels strange to have a field in a generic library crate that's tied to a specific piece of software like that so just wanted to understand. Do you have a specific RFC that describes the format you are coding to? The link on the README goes to wikipedia, which links to an RFC that says 'DO NOT USE' at the top but I have no idea what the reference should be otherwise.

Thanks!

Serde parse error is very vague with errors like the following:

error: missing field `headersSize` at line 1 column 1

or

error: invalid type: boolean `false`, expected a string at line 1 column 1

Ideally serde would send back the real line number and possibly column.

I found debugging the failing parsing excruciating with the untagged enum approach; I hope you'll consider the refactoring I've done here, though if its a problem, now that it parses, I can switch it back to untagged.

I observed tests not being run on my platform ... The tests were in fact broken:

• the fixtures were not located due to a faulty glob
• the sample har file was invalid JSON
• the round trip test failed due to about a thousand missing "comment" fields.

I chose to remove the "" valued comment fields rather than adding all the missing ones, as eliding optional fields is entirely in spec.

This reverts commit 945247b46676d256dd33cdcf99af8297bc27fdd1, which checked in the lockfile.

It was a blunder from my side, forgetting that har-rs is a library and not a binary, and that different Rust conventions apply then.

This PR removes the _charlesStatus field that snuck into the codebase, fixing #13.

It also: • Fixes a regression in the test fixtures introduced by #8 • Some minor maintenance and refactoring, like removing or bumping deps and using a macro to remove some repetitive serde annotations.

This PR is mainly about migrating to Rust 2018 (using $ cargo fix --edition).

The error_chain macro is now deprecated, but Rust's failure isn't a mature option either, so I'm silencing that deprecation warning for now.

Currently, for some reason, the CI/CD fails when trying to publish a new release/crate.

I'm noticing some discrepancies between using mandrean/semantic-rs locally, and the exact same version of it remotely.

For example, running mandrean/semantic-rs locally @ 10cc3d2d17056d498627cc2afb2ec23e104acac3 results in a bump to 0.6.1, but in the CI it becomes 0.7.0.

Needs further investigation.