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.keu...@xs4all.nl] > Sent: Saturday, July 15, 2017 5:43 AM > To: Developer support list for Wireshark <wireshark-dev@wireshark.org> > Cc: Sultan, Hassan <sul...@amazon.com> > 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- > d...@wireshark.org> 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. > ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
