HTTP/2 + HAR v1.3

[Ahmad Nassri]

Hello everyone, 

I've been working with HTTP/2 a lot recently, and one of the obvious shortcomings I'm finding with v1.2 is header size compression tracking ...

so I figured its worth starting a conversation to what else (if any) needs to be reflected in an updated spec version dealing with changes in HTTP/2

so far the header compression size is the only one I came across, following the example of the "response.content.size" & "response.content.compression" may I suggest one of two changes:

"headersCompression" to follow along the "headersSize" property on the request and response objects? (backward compatible)

[Jan Honza Odvarko]

Thanks for the topic!

The description for "response.content.compression" and "request.content.compression" is:

compression [number, optional] - Number of bytes saved. Leave out this field if the information is not available.

Do we follow the same logic?

headersCompression [number, optional] - Number of bytes saved. Leave out this field if the information is not available.

Honza

[Ahmad Nassri]

I vote for following the same logic here, yes.

[Ahmad Nassri]

I also noticed something today (just now actually)

the response content object allows for encoding the body text (e.g. base64, which is extremely helpful) but the request object has no equivalent declaration.

in both the postParams object and within a multi-part param object

so as part of the 1.3 discussion here, I suggest including an optional encoding property on the following:

"postData": {

    "mimeType": "text/html; charset=utf-8",

         "text" : "PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5Lz48L2h0bWw+XG4=",

    "encoding": "base64"

}

"params": [

    {

        "name": "page",

        "value": "PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5Lz48L2h0bWw+XG4=",
        "encoding": "base64",

        "fileName": "example.html",

        "contentType": "text/html",

        "comment": ""

    }

]

[Ahmad Nassri]

Hey guys, 

poking on these suggested updates to the spec and if the community agrees, I see great value in introducing v1.3 with those changes.

specifically with http2 wide adoption by now and the issue described prior on encoding request body content

[Ahmad Nassri]

following up on this discussion, I've created a github repo and transfer the 1.2 spec over and created a 1.3 proposal: https://github.com/ahmadnassri/har-spec

a github repo with markdown format makes it a lot easier for edits / suggestions and community contribution.

feedback welcome, and if the github approach is agreeable, we can setup an "org" and move away from my account, so its community driven and Jan can be an owner as well.

thanks.

[all...@chromium.org]

Here on chrome devtools we are planning on a bit of changes involving network/resources, timing and import/export. We are heavily interested in a newer HAR spec that would support much of the new technologies available. I'd be personally happy to help develop a new spec with you and use this new spec as our basis for import/export for analysis.

As for describing HTTP2 info, here is some info worth discussing:

* Push Promise information (including timing)

* Resource priority and priority changes

* Define how upgrade requests from HTTP1.1 to h2 are surfaced

* Field for streamID

* Ping packets

* HTTP2 connection settings

* Frame details (like size of frame, ack, and timings)

Some other things worth discussing:

* Initiator data

* Packet loss

* Some kind of histogram of speed data was received/sent

* Although Quic is not common yet, it introduces the ability to send multiple copies of the same packet.

Obviously many of these will not be defined in this spec, but they are worth discussing.

[Ahmad Nassri]

allada,

excellent! glad to hear there is interest, Andrew Robbins (cc-ed) and I have been discussing more potentially valuable updates to the spec and are tracking that on the same repo: https://github.com/ahmadnassri/har-spec/pulls (particularly of interest are Andrew's suggestions on postData and timings improvements)

(I feel that github is a great medium for allowing people to add suggestions and discussions, beyond a mailing list) happy to donate that repo to the an official group / committee that can oversee collaborative work on the spec, but of course the browser vendors are key to this collaboration.

I've recently joined the Open API Initiative in forming the future of Open API Spec (formerly known as Swagger) and we're seeing some success in having an official group of committed owners from businesses directly interacting with the spec and leading its evolution.

I'm going to post this thread and discussion as well on https://discuss.httparchive.org as there's parallel discussions going on there around upgrading the spec as well.