Wireshark mailing list archives
Re: digging something meaningful out of xmlrpc
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Tue, 15 Feb 2011 19:23:44 +0200
Thank you for the tip. However my problem is not so much about being able to do the job of parsing the XML. It is a more a philosophical/API question. Is it ok to dissect something in a way that leaves lots of bytes unexplained? Also, is it possible to show a more general and a less general dessections of the same data? I am looking at OpenDHT client interface here. The protocol parses as XML, but it also parses as XML-RPC, and as an OpenDHT function call. If I take it to the level of showing information relevant for an OpenDHT function call I will have to ignore most of the XML because it is just meta data that tells me where the payload is, and showing that to the user makes the result harder to understand. It is also a quesiton of user interface design. If I can parse something as an OpenDHT function call and show the meaningful results for that, should we still show the parsed XML for someone who is interested for the validity of the xml, or wants to look it up for features that are not part of the default OpenDHT protocol. Is it ok to dissect a dictionary and only explain the keys you know about, or do I need to stop dissecting, if I suddenly find out there is one key that I do not recognize because it is part of some obscure extension? On Tue, Feb 15, 2011 at 6:54 PM, David Young <dyoung () pobox com> wrote:
On Tue, Feb 15, 2011 at 03:05:47PM +0200, Toni Ruottu wrote:I am using Wireshark to analyse services that use XML-RPC calls to communicate. Currently the protocol gets dissected as XML which is fine because it is XML. However the result has lots of bloat that makes it hard for me to analyse the protocol built on top of XML-RPC. Can I somehow write a dissector (?) that analyses only the interesting parts of the protocol, and shows its results "on top" of the more generix XML-RPC dissection, as an alternative way of interpreting the same data. Note that being able to add detail into the atomic parts of dissected XML-RPC does not help, as it is the verboseness of XML-RPC that gets in the way.I mentored a Google Summer of Code student in 2009 who produced stream-oriented XML filter/transform tools, <http://netbsd-soc.sourceforge.net/projects/xmltools/>. Maybe the tools or the corresponding C library will help. Dave -- David Young OJC Technologies dyoung () ojctech com Urbana, IL * (217) 344-0444 x24 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- digging something meaningful out of xmlrpc Toni Ruottu (Feb 15)
- Re: digging something meaningful out of xmlrpc David Young (Feb 15)
- Re: digging something meaningful out of xmlrpc Toni Ruottu (Feb 15)
- Re: digging something meaningful out of xmlrpc David Young (Feb 15)