Ethereal-dev: SV: [Ethereal-dev] New dissector for content type multipart/mixed

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Anders Broman" <a.broman@xxxxxxxxx>
Date: Sat, 10 Jan 2004 01:47:14 +0100
Hi,
First :
Some warnings:

>packet-multipart_mixed.c:146:60: warning: multi-character character 
>constant
Not fixed as I'm unshure how the line would end when it's unquoted
' ' CRLF or .. help appreciated.

>packet-multipart_mixed.c: In function `dissect_multipart_mixed':
>packet-multipart_mixed.c:126: warning: unused variable `next_offset'
>packet-multipart_mixed.c:129: warning: unused variable `found_match'
>packet-multipart_mixed.c: In function `dissect_header_and_body':
>packet-multipart_mixed.c:248: warning: `found_match' might be used 
>uninitialized in this function
Fixed I hope as the don't show up on my box.

>Also, it's using "tvb_offset_exists()" in the main loop; that will stop 
>at the end of the captured data, rather than the end of the real data - 
>it should continue to the end of the real data, so that it throws the 
>appropriate exception for short captures.

Well this dissector gets handed the data in a tvb by the previous
Dissector and the Content-lenght isn't known .. or am I missing something?

As for the short names or not I was thinking that the likely hood of 'c='
as the first two chars on a line turning up in the header in a HTTP message
is slim?

The case sensitive checking is copied from the SIP dissector, off hand
I can't remember which parts are case sensitive and which are not according
to the RFC. Can we check it in as it is for now and I'll check the spec's
later, and send in a fix if needed ?
Best regards
Anders

-----Ursprungligt meddelande-----
Från: Olivier Biot [mailto:ethereal@xxxxxxxxxx] 
Skickat: den 10 januari 2004 01:27
Till: Guy Harris; Anders Broman
Kopia: ethereal-dev@xxxxxxxxxxxx
Ämne: Re: [Ethereal-dev] New dissector for content type multipart/mixed

That's a good idea.

I'd also like to have multipart/related (and other multipart types) in this
dissector. For this reason, maybe the dissector could be called
"packet-multipart-media.c" in which all multipart dissectors are grouped
(they don't really differ a lot).

I will soon add a generic line-based text dissector (a copy of the
message/http dissector I checked in earlier today). That will help testing
the multipart dissection :)

Regards,

Olivier
----- Original Message ----- 
From: "Guy Harris"

On Jan 9, 2004, at 3:54 PM, Olivier Biot wrote:

> Your dissector also applies to HTTP (except for the short header field
> names as is customary in SIP). Maybe we should add dissect_from_sip()
> and dissect_from_http() methods, and then let them have dedicated
> is_multipart_http_header() and is_multipart_sip_header() methods?

Or just a Boolean to specify whether short header field names should be
accepted?

That should perhaps be passed to media-type dissectors via the
private_data structure.



Attachment: packet-multipart_mixed.c
Description: Binary data