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

["Bryant Eastham" <beastham@xxxxxxxxxxx>]

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
>
>
>
>
>