Ethereal-dev: Re: [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: "Olivier Biot" <ethereal@xxxxxxxxxx>
Date: Sat, 10 Jan 2004 01:56:14 +0100
----- Original Message ----- 
From: "Anders Broman"

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.

--> Try the code below:

len = tvb_find_line_end(tvb, offset,
     tvb_ensure_length_remaining(tvb, offset),
     &next_offset, FALSE);
if (len == -1) { /* End of tvbuff_t before line end */
    ; /* Do something here */
}
etc... may help you here.

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

--> Difference between captured and reported data: yuor packet may
have been 1000 bytes but truncated to 100 bytes.

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?

--> OK for me today

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.

--> Header name is case INsensitive; header value is case sensitive.

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

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.