Re: hf_http_response_code in packet-http.c

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

Le 13 juil. 2017 19:54, "Sultan, Hassan" <sultah () amazon com> a écrit :



> -----Original Message-----
> From: Pascal Quantin [mailto:pascal.quantin () gmail com]
> Sent: Thursday, July 13, 2017 10:39 AM
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> Cc: Sultan, Hassan <sultah () amazon com>
> Subject: Re: [Wireshark-dev] hf_http_response_code in packet-http.c
>
> Hi Hassan,
>
>
> 2017-07-13 19:25 GMT+02:00 Sultan, Hassan via Wireshark-dev <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> ] 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: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: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 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.

My reason is that anyone wanting to build automation based on Wireshark's
parsing will not be able to rely on Wireshark's reporting of field type &
format to interpret the packet data.
The automation would walk through parsed fields and be told that the http
response code is a 3-bytes UINT16 with value say 200, so bytes 00 00 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, but it
is far from ideal for automation.


Thanks fact that HTTP is text based does not change the fact that the code
is supposed 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?


Thanks,

Hassan

___________________________________________________________________________
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