Re: hf_http_response_code in packet-http.c

[Pascal Quantin <pascal.quantin () gmail com>]

Hi Hassan,

2017-07-13 19:25 GMT+02:00 Sultan, Hassan via Wireshark-dev <
wireshark-dev () wireshark org>:

> > -----Original Message-----
> > From: Wireshark-dev [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>
> > Subject: Re: [Wireshark-dev] hf_http_response_code in packet-http.c
> >
> >
> >
> > On Thu, Jul 13, 2017 at 1:12 AM, Sultan, Hassan via Wireshark-dev
> <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 a FT_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 field as
> FT_UINT16 ? My understanding of generated fields is that this is their
> purpose : represent data that doesn't exactly correspond to the packet data.
> We could still keep the field named as is today (hence ensuring all
> existing filters still work), but simply make it a generated field, and add
> an 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 any issue? For
fields having numerical values only, it makes much more sense to have the
digits directly instead of the string and that's already what we are doing
in numerous places. And personally I do not see any valid reason to change
that. Your suggestion implies that many fields would start to be duplicated
without any added value.

Best regards,
Pascal.

___________________________________________________________________________
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