Wireshark mailing list archives
Re: hf_http_response_code in packet-http.c
From: Erik de Jong <erikdejong () gmail com>
Date: Thu, 13 Jul 2017 20:58:28 +0200
On Thu, Jul 13, 2017 at 8:47 PM, Sultan, Hassan via Wireshark-dev < wireshark-dev () wireshark org> wrote:
-----Original Message----- From: Pascal Quantin [mailto:pascal.quantin () gmail com] Sent: Thursday, July 13, 2017 11:26 AM To: Sultan, Hassan <sultah () amazon com> Cc: Developer support list for Wireshark <wireshark-dev () wireshark org> Subject: RE: [Wireshark-dev] hf_http_response_code in packet-http.c Le 13 juil. 2017 19:54, "Sultan, Hassan" <sultah () amazon com <mailto:sultah () amazon com> > a écrit : > -----Original Message----- > From: Pascal Quantin [mailto:pascal.quantin () gmail com <mailto:pascal.quantin () gmail com> ] > Sent: Thursday, July 13, 2017 10:39 AM > To: Developer support list for Wireshark <wireshark- dev () wireshark org <mailto:wireshark-dev () wireshark org> > > Cc: Sultan, Hassan <sultah () amazon com <mailto:sultah () amazon com> > > Subject: Re: [Wireshark-dev] hf_http_response_code inpacket-http.c> > Hi Hassan, > > > 2017-07-13 19:25 GMT+02:00 Sultan, Hassan via Wireshark-dev <wireshark- > dev () wireshark org <mailto:dev () wireshark org> <mailto:wireshark- dev () wireshark org <mailto:wireshark-dev () wireshark org> > >: > > > > > > -----Original Message----- > > From: Wireshark-dev [mailto:wireshark-dev- bounces () wireshark org <mailto:wireshark-dev-bounces () wireshark org> > <mailto:wireshark-dev-bounces () wireshark org <mailto:wireshark- dev-bounces () wireshark org> > ] On Behalf > > Of Erik de Jong > > Sent: Wednesday, July 12, 2017 10:12 PM > > To: Developer support list for Wireshark <wireshark- > dev () wireshark org <mailto:dev () wireshark org> <mailto:wireshark- dev () wireshark org <mailto:wireshark-dev () wireshark org> > > > > Subject: Re: [Wireshark-dev] hf_http_response_code inpacket-http.c > > > > > > > > On Thu, Jul 13, 2017 at 1:12 AM, Sultan, Hassan viaWireshark-dev > <wireshark- > > dev () wireshark org <mailto:dev () wireshark org> <mailto:dev () wireshark org <mailto:dev () wireshark org> > <mailto:wireshark-<mailto:wireshark-> > dev () wireshark org <mailto:dev () wireshark org> <mailto:wireshark- dev () wireshark org <mailto:wireshark-dev () wireshark org> > > > wrote: > > > > > > Hi, > > > > > > > > I am starting to learn the Wireshark code base,and one thing> puzzles > > me… > > > > > > > > Why is hf_http_response_code defined as aFT_UINT16 with> BASE_DEC > > rather than an FT_STRING ? > > > > > > > > It’s a text field… not an integer. > > > > > > Presenting it as a number allows for filtering like: > > http.response.code > 200 > > > > Which would not be possible when presented as a string. > > Thanks for the info, but in that case would it not be more appropriate to > have the normal field as an FT_STRING and add a generated fieldasFT_UINT16 > ? My understanding of generated fields is that this is theirpurpose :represent > data that doesn't exactly correspond to the packet data. > We could still keep the field named as is today (henceensuring all> existing filters still work), but simply make it a generatedfield, and addan > FT_STRING to represent the actual data as it is in the packet. > > Thoughts ? > > > > > Does having the field as it is designed today generating you anyissue?For fields > having numerical values only, it makes much more sense to havethedigits > directly instead of the string and that's already what we aredoing innumerous > places. And personally I do not see any valid reason to changethat.Your > suggestion implies that many fields would start to be duplicated without any > added value. My reason is that anyone wanting to build automation based on Wireshark's parsing will not be able to rely on Wireshark's reporting offield type& format to interpret the packet data. The automation would walk through parsed fields and be told thatthehttp response code is a 3-bytes UINT16 with value say 200, so bytes 0000 c8,which is wrong. Right now the way these fields are setup works for human interpretation, by people looking at the rendered value on a screen, butit is farfrom ideal for automation. Thanks fact that HTTP is text based does not change the fact that thecode issupposed to be a number. So I'm not sure to get your point. Moreover tons of people use tshark for automation and I do not remember someone complaining about the current output. So maybe I simply did not understand your use case. One could argue it's the main purpose of Wireshark, but I think it needlessly prevent a whole class of use-cases from being achieved with Wireshark's technology. Could you elaborate? What use case do you have in mind exactly?Imagine automation that attempts to perform modification on packets using the parsed information provided by Wireshark, or somehow goes and directly reads fields in the packet data based on what Wireshark's parsed information says (type/offset/length/...). Wireshark reporting the field as FT_UINT16 instead of say a UTF-8 FT_STRING throws off the automation as it would either attempt to write an FT_UINT16 at the offset of the field, writing the wrong format, or be confused by seeing a 3 bytes FT_UINT16 and give up.
But in that case it's more like you're doing a part of the parsing in another application, why not implement a full parser in that application? The whole point of an analyzer is to make sense of the data passed into it for the user. And what about protocols that could be send with different encodings (BER, XER, etc) there a field type should still be the same - eg UINT16 - but the representation on the wire is totally different.
How about having an #ifdef for such things so that Wireshark's use-case today does not have to suffer the addition of generated fields, and such automation cases could still get full fidelity parsing by building Wireshark's engine with the specific #define ? Today they have to build directly against Wireshark's code anyway so that shouldn't be a problem. ____________________________________________________________ _______________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.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: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 12)
- Re: hf_http_response_code in packet-http.c Erik de Jong (Jul 12)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 13)
- Re: hf_http_response_code in packet-http.c Pascal Quantin (Jul 13)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 13)
- Re: hf_http_response_code in packet-http.c Pascal Quantin (Jul 13)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 13)
- Re: hf_http_response_code in packet-http.c Erik de Jong (Jul 13)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 13)
- Re: hf_http_response_code in packet-http.c Pascal Quantin (Jul 13)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 13)
- Re: hf_http_response_code in packet-http.c Jaap Keuter (Jul 15)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 17)
- Re: hf_http_response_code in packet-http.c Anders Broman (Jul 17)
- Re: hf_http_response_code in packet-http.c Guy Harris (Jul 17)
- Re: hf_http_response_code in packet-http.c Sultan, Hassan via Wireshark-dev (Jul 13)
- Re: hf_http_response_code in packet-http.c Erik de Jong (Jul 12)