Wireshark · Wireshark-dev: Re: [Wireshark-dev] Further HTTP woes...

["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

checked in

On 9/11/06, Bryant Eastham <beastham@xxxxxxxxxxx> wrote:
> Thanks. I have verified that it works.
>
> Compiling under Windows (cygwin, actually) I had to manually build the
> codecs/codecs.lib library.
>
> Also, there is still an outstanding issue regarding the default use of
> the "media" dissector. The way it is currently coded there is no way to
> have a heuristic decoder when a content-type header is specified.
>
> I propose the following patch:
>
> $ svn diff epan/dissectors/packet-http.c
> Index: epan/dissectors/packet-http.c
> ===================================================================
> --- epan/dissectors/packet-http.c       (revision 19188)
> +++ epan/dissectors/packet-http.c       (working copy)
> @@ -1097,12 +1097,6 @@
>                         handle = dissector_get_string_handle(
>                             media_type_subdissector_table,
>                             headers.content_type);
> -                       /*
> -                        * Calling the default media handle otherwise
> -                        */
> -                       if (handle == NULL) {
> -                           handle = media_handle;
> -                       }
>                 }
>                 if (handle != NULL) {
>                         /*
> @@ -1127,8 +1121,16 @@
>                         if (ti != NULL)
>                                 proto_item_set_len(ti, offset);
>                 } else {
> -                       /* Call the subdissector (defaults to data) */
> -                       http_payload_subdissector(next_tvb, tree,
> http_tree, pinfo);
> +                       if (headers.content_type != NULL) {
> +                               /*
> +                                * Calling the default media handle if
> there is a content-type that
> +                                * wasn't handled above.
> +                                */
> +                               call_dissector(media_handle, next_tvb,
> pinfo, tree);
> +                       } else {
> +                               /* Call the subdissector (defaults to
> data), otherwise. */
> +                               http_payload_subdissector(next_tvb,
> tree, http_tree, pinfo);
> +                       }
>                 }
>
>         body_dissected:
>
> In this way if there is a decoder for a specific content-type then it
> will be used, then the heuristic decoders have a chance, and finally the
> default of either the media-type decoder of the http_payload decoder.
>
> Thoughts? Someone care to apply it?
>
> Thanks again for getting the other issues resolved. The combination of
> these two will allow my plugin development to continue.
>
> Bryant Eastham
>
>
> -----Original Message-----
> From: ronnie sahlberg [mailto:ronniesahlberg@xxxxxxxxx]
> Sent: Sunday, September 10, 2006 11:05 PM
> To: Developer support list for Wireshark
> Cc: Bryant Eastham
> Subject: Re: Further HTTP woes...
>
> Please try SVN19185 or later
> It works on my captures.
>
>
> On 9/7/06, Bryant Eastham <beastham@xxxxxxxxxxx> wrote:
> > Thank you! My intent was really not to add more work to others, but to
>
> > investigate how to solve the problem on my own. I appreciate your
> offer.
> > Since that solution is "real", I will not spend any time on my
> > "conversation" hack.
> >
> > Thanks again,
> > Bryant
> >
> > ________________________________
> >
> > From: wireshark-dev-bounces@xxxxxxxxxxxxx
> > [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of ronnie
> > sahlberg
> > Sent: Thursday, September 07, 2006 5:47 PM
> > To: Developer support list for Wireshark
> > Subject: Re: [Wireshark-dev] Further HTTP woes...
> >
> >
> > :-)
> >
> >
> > I have example captures of some x509 related protocols running atop
> > http which show this.
> >
> > I will try to look into implementing this in the tcp layer this
> weekend.
> >
> >
> >
> > On 9/8/06, Bryant Eastham <beastham@xxxxxxxxxxx> wrote:
> >
> >  What nagle algorithm! Did I forget to mention that we *wrote* the
> > TCP/IP  stack and that it is running on a small microprocessor? ;-)
> >
> >  Seriously, this behavior is coming out of Tomcat Web
> > Server/3.3.1 Final
> >  (JSP 1.1; Servlet 2.2). We do, however, have our own implementations
> > in  which nagle is not available. I would have to check with the
> > developer  to see if he has disabled anything - I doubt it.
> >
> >  Thanks,
> >  Bryant
> >
> >  ________________________________
> >
> >  From: wireshark-dev-bounces@xxxxxxxxxxxxx
> >  [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx ] On Behalf Of ronnie
> > sahlberg
> >  Sent: Thursday, September 07, 2006 5:32 PM
> >  To: Developer support list for Wireshark
> >  Subject: Re: [Wireshark-dev] Further HTTP woes...
> >
> >
> >  "I now have the following problem. It is common for our
> > implementation  to  dump the headers in one segment and then dump the
> > data in the next, with  no Content-Length."
> >
> >  Why does it send this as two segments?
> >  You have not disabled NAGLE have you?
> >
> >  _______________________________________________
> >  Wireshark-dev mailing list
> >  Wireshark-dev@xxxxxxxxxxxxx
> >  http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
> >
> >
> >
> >