Timings may be expressed as numbers, not just integers

[michaek]

It seems that the HTTP Archive spec doesn't require that timings be integers, just "numbers". The reason this seems worth mentioning is that Chrome's "copy to har" creates a HAR with timings expressed as floating point numbers, and it seems worthwhile to support the format. Would this just be a matter of changing the jschematic schemas?

[jarib]

Yes, if you change the schemas, that will fix validation (which is what I assume you're after).

[jarib]

Actually, the schema is also found in the bundled har viewer (lib/har/viewer/scripts/preview/harSchema.js). That's probably where I got the schemas used in the Ruby code originally.

Perhaps it's better to get the latest viewer from http://code.google.com/p/harviewer/ and re-extract the schema from there - assuming the viewer has the correct schema of course.

[michaek]

I had just come to the same conclusion. :) I'll take a look today.

On Tuesday, January 21, 2014, Jari Bakken notifications@github.com wrote:

Actually, the schema is also found in the bundled har viewer
(lib/har/viewer/scripts/preview/harSchema.js). That's probably where I got
the schemas used in the Ruby code originally.

Perhaps it's better to get the latest viewer from
http://code.google.com/p/harviewer/ and re-extract the schema from there

• assuming the viewer has the correct schema of course.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-32870515
.

[michaek]

Did you convert the harviewer PHP to HTML by hand? It seems that there's next to no actual PHP in them, merely including the Google Analytics script, so it may be safe enough to simply treat them as HTML or strip out the PHP "tags". What are your thoughts?

[jarib]

I don't recall there being PHP in the viewer code, but if it's for GA, let's strip them out.

[michaek]

Sounds good.

[michaek]

The edge version of harviewer has the same issue, and I've opened a ticket there. I've got an as-yet-uncommitted thor task that grabs the most recent harviewer master (via Bower), strips the PHP and renames files to HTML, then copies the whole shebang to vendor/viewer.

Because this has uncertain benefit, and it changes the behavior of the gem by no longer including the harviewer dependency code, I'm not sure if a pull request would be welcome. I'll probably commit and push to my fork tomorrow if you'd like to take a look.

[jarib]

Sure, ping me when you've pushed (or just submit the PR) and I'll take a look.

[michaek]

Here's the branch with the changes - I don't want to do a pull request, because I don't think Bower is actually appropriate, upon reflection. https://github.com/michaek/har/tree/feature/bower_dependency

[jarib]

Gotcha. I like the idea of making it easy to update the viewer though.

[michaek]

I made a note in that branch's Readme about what I think a better design would be for allowing easier updates. It seems like the ideal way to handle it would be to simply change a gem depencency: gem 'harviewer_ruby', '2.1.5' The thor task and Bundler dependency would just be part of the build process for harviewer_ruby, and the har gem's signature shouldn't need to change.

[michaek]

I suppose it's more conventional to name it ruby_harviewer. :)

[jarib]

Yeah, that would work. It seems a bit overkill to me though, having two gems for such a small utility.

[michaek]

harviewer has just fixed this in 2.0.16 janodvarko/harviewer#7

[jarib]

I've just pushed a 0.1.0 gem with harviewer updated to 2.0.16. I'm still seeing problems with Chrome-generated hars though:

I've opened a Chromium bug for this.