- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Thu, 23 Mar 2023 03:25:52 +0000
- To: HTTP Working Group <ietf-http-wg@w3.org>, ohai@ietf.org
- Message-ID: <CALGR9oYvTDbTyAYEX05OGpQdx9BvVfE0rM1wc3NyQ8cLzs5Avg@mail.gmail.com>
Hi folks, Specs are great but when it comes to trying to understand how a protocol works, being able to demo and dissect it can be a good learning aid. To this end, I spent a little bit if time making a dissector for Wireshark*. This is invoked via registering a new handler for the message/bhttp. I've opened a Merge Request on Wireshark [1], if people would like to kick the tyres on it, I would appreciate that. If you have pcaps from bHTTP implementations that'd be useful too. Once I got 90% of the way through, I realised the value of this bHTTP dissector is limited. It will truly shine once it can integrate with an Oblivious HTTP dissector. That sadly doesnt exist yet, it requires more work, mainly to obtain and use the keys that would let us recurse down into messages. I've spoken to a few people about this and we have some ideas. I'll be around at the IETF 116 hackathon in case anyone wants to chat about that. Cheers Lucas * the meta/inception here is that I also wanted to use this process to also better understand how to write dissectors. It works but there are some rough edges that I expect the review process to shape up. The use of QUIC varints didn't pose much problem, I leaned heavily on the code Alexis Lagoutte, Peter Wu and others contributed to the extant QUIC and HTTP/3 dissectors in this respect. [1] - https://gitlab.com/wireshark/wireshark/-/merge_requests/10067
Received on Thursday, 23 March 2023 03:26:17 UTC