Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-commits: [Wireshark-commits] rev 41025: /trunk/epan/dissectors/ /trunk/epan/dissectors/:

Date: Tue, 14 Feb 2012 06:00:15 GMT
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=41025

User: guy
Date: 2012/02/13 10:00 PM

Log:
 To quote section "7.2.1 Type" of RFC 2068, "Hypertext Transfer Protocol
 -- HTTP/1.1":
 
    Any HTTP/1.1 message containing an entity-body SHOULD include a
    Content-Type header field defining the media type of that body. If
    and only if the media type is not given by a Content-Type field, the
    recipient MAY attempt to guess the media type via inspection of its
    content and/or the name extension(s) of the URL used to identify the
    resource. If the media type remains unknown, the recipient SHOULD
    treat it as type "application/octet-stream".
 
 To quote section "4. Encoding of Transport Layer" of RFC 2565, "Internet
 Printing Protocol/1.0: Encoding and Transport":
 
    HTTP/1.1 [RFC2068] is the transport layer for this protocol.
 
 	...
 
    Note: even though port 631 is the IPP default, port 80 remains the
    default for an HTTP URI.  Thus a URI for a printer using port 631
    MUST contain an explicit port, e.g. "http://forest:631/pinetree";.  An
    HTTP URI for IPP with no explicit port implicitly reference port 80,
    which is consistent with the rules for HTTP/1.1. Each HTTP operation
    MUST use the POST method where the request-URI is the object target
    of the operation, and where the "Content-Type" of the message-body in
    each request and response MUST be "application/ipp". The message-body
    MUST contain the operation layer and MUST have the syntax described
    in section 3.2 "Syntax of Encoding". A client implementation MUST
    adhere to the rules for a client described for HTTP1.1 [RFC2068]. A
    printer (server) implementation MUST adhere the rules for an origin
    server described for HTTP1.1 [RFC2068].
 
 So, when choosing a subdissector for HTTP request bodies, search based
 on the media type first, and only if we *don't* find a dissector for the
 media type, do other stuff such as heuristics or choosing a subdissector
 based on the port number.
 
 This fixes a number of problems; in particular, it fixes bug 6765
 "non-IPP packets to or from port 631 are dissected as IPP" without
 requiring the IPP dissector to attempt to determine whether an entity
 body looks like IPP.  It also ensures that the default dissector for
 HTTP entity bodies, the "media" dissector, will get the media type
 passed to it in pinfo->match_string.
 
 Don't use "!str*cmp()" while we're at it - it's valid C, but the "!" can
 make it look as if it's checking for something not being the case when,
 in fact, you're checking for equality rather than inequality.  (The
 str*cmp() routines don't return Boolean results.)

Directory: /trunk/epan/dissectors/
  Changes    Path             Action
  +17 -7     packet-http.c    Modified