diff options
| -rw-r--r-- | packet-http.c | 35 | ||||
| -rw-r--r-- | packet-ipp.c | 16 |
2 files changed, 31 insertions, 20 deletions
diff --git a/packet-http.c b/packet-http.c index c427905656..9e899afe74 100644 --- a/packet-http.c +++ b/packet-http.c @@ -3,7 +3,7 @@ * * Guy Harris <guy@alum.mit.edu> * - * $Id: packet-http.c,v 1.33 2001/01/09 06:31:36 guy Exp $ + * $Id: packet-http.c,v 1.34 2001/01/11 05:36:09 guy Exp $ * * Ethereal - Network traffic analyzer * By Gerald Combs <gerald@zing.org> @@ -61,6 +61,8 @@ static gint ett_http = -1; #define TCP_PORT_PROXY_ADMIN_HTTP 3132 #define TCP_ALT_PORT_HTTP 8080 +#define TCP_PORT_IPP 631 + #define TCP_PORT_SSDP 1900 #define UDP_PORT_SSDP 1900 @@ -99,12 +101,12 @@ dissect_http(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree) switch (pinfo->match_port) { - case 631: + case TCP_PORT_IPP: proto = PROTO_IPP; proto_tag = "IPP"; break; - case 1900: + case TCP_PORT_SSDP: /* TCP_PORT_SSDP = UDP_PORT_SSDP */ proto = PROTO_SSDP; proto_tag = "SSDP"; break; @@ -401,8 +403,31 @@ proto_reg_handoff_http(void) proto_http); dissector_add("tcp.port", TCP_PORT_PROXY_ADMIN_HTTP, dissect_http, proto_http); - dissector_add("tcp.port", 631, dissect_http, proto_http); - + + /* + * XXX - this is a bit ugly; we probably really want to have + * protocols based atop HTTP call a routine to register + * themselves with the HTTP dissector, giving an optional + * port number (if the port number is "missing", e.g. -1 or 0, + * the protocol would be assumed to use a standard HTTP port), + * and an optional Content-Type: value (or some other way for + * the dissector to tell what the next protocol is). + * + * The HTTP dissector would register itself for the port in + * question (if it's not missing), and would use either the + * port number or the Content-Type: (or whatever) value to + * determine whether to hand the payload to that dissector. + * + * It would also pass a protocol number, so we could arrange + * that the HTTP part of an IPP packet be dissected iff HTTP + * is enabled, and the IPP part be dissected iff IPP is enabled. + */ + dissector_add("tcp.port", TCP_PORT_IPP, dissect_http, proto_http); + + /* + * XXX - is there anything to dissect in the body of an SSDP + * request or reply? I.e., should there be an SSDP dissector? + */ dissector_add("tcp.port", TCP_PORT_SSDP, dissect_http, proto_http); dissector_add("udp.port", UDP_PORT_SSDP, dissect_http, proto_http); diff --git a/packet-ipp.c b/packet-ipp.c index 4ae61b6e7f..2df6670bc4 100644 --- a/packet-ipp.c +++ b/packet-ipp.c @@ -3,7 +3,7 @@ * * Guy Harris <guy@alum.mit.edu> * - * $Id: packet-ipp.c,v 1.19 2001/01/09 06:31:37 guy Exp $ + * $Id: packet-ipp.c,v 1.20 2001/01/11 05:36:09 guy Exp $ * * Ethereal - Network traffic analyzer * By Gerald Combs <gerald@zing.org> @@ -569,17 +569,3 @@ proto_register_ipp(void) */ register_dissector("ipp", dissect_ipp, proto_ipp); } - -void -proto_reg_handoff_ipp(void) -{ - /* XXX - should we just register ourselves as a dissector, - and call the HTTP dissector? - - Should we pass to it a pointer to our dissector, so that - it knows to call us? - - Or should the HTTP dissector decide that the payload is - IPP based on the MIME headers? */ - dissector_add("tcp.port", 631, dissect_http, -1); /* XXX */ -} |