One thing we could do rather than create more fields is to keep the fields as-is, but find a way to store in the header_field_info structure attached to the field the original type & encoding (meaning : what the field actually is on the wire).
The current field_info seems to properly represent length & offset (at least for the cases in http), so really the important stuff missing is data type & encoding. Storing that in the header_field_info would limit the memory consumption increase as well since it wouldn't grow with the # of frames parsed.
Thanks,
Hassan
> -----Original Message-----
> From: Jaap Keuter [mailto:jaap.keuter@xxxxxxxxx]
> Sent: Saturday, July 15, 2017 5:43 AM
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Cc: Sultan, Hassan <sultah@xxxxxxxxxx>
> Subject: Re: [Wireshark-dev] hf_http_response_code in packet-http.c
>
> Hi all,
>
> I remember a similar discussion around the Contents-Length header some years
> ago.
> Can’t we make a similar solution here? Then everyone will be happy and we
> have a backwards compatible solution.
>
> Thanks,
> Jaap
>
>
> > On 13 Jul 2017, at 22:41, Sultan, Hassan via Wireshark-dev <wireshark-
> dev@xxxxxxxxxxxxx> wrote:
> >
> >
> >
> >
> >> As Eric explained, having the HTTP response code as a number simply
> >> gives you much more advantages (filtering, comparisons,
> >> inequalities...) than having it in text. So this is clearly not a bug as it was done
> on purpose.
> >
> > I agree it's not a bug. For the existing purpose of Wireshark it does the job. It
> just makes some other use-cases a bit more difficult.
>