Excerpt: Section 3 of RFC 2184, "Parameter Value Continuations".

 The obvious solution, then, is to use multiple parameters to contain
 a single parameter value and to use some kind of distinguished name
 to indicate when this is being done.  And this obvious solution is
 exactly what is specified here: The asterisk character ("*") followed
 by a decimal count is employed to indicate that multiple parameters
 are being used to encapsulate a single parameter value.  The count
 starts at 0 and increments by 1 for each subsequent section of the
 parameter value.  Decimal values are used and neither leading zeroes
 nor gaps in the sequence are allowed.
 The original parameter value is recovered by concatenating the
 various sections of the parameter, in order.  For example, the
 content-type field
   Content-Type: message/external-body; access-type=URL;
 is semantically identical to
   Content-Type: message/external-body; access-type=URL;
 Note that quotes around parameter values are part of the value
 syntax; they are NOT part of the value itself.  Furthermore, it is
 explicitly permitted to have a mixture of quoted and unquoted
 continuation fields.

Example from Thunderbird 2.0:

Content-Type: application/msword;
 name="NEUE lettera d'ass. 
Content-Transfer-Encoding: base64
Content-Disposition: inline;

Example from Outlook 11 (no continuation):

Content-Type: application/msword;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

Proposed code for the simple part of filename detection:

  if (!getDispositionParameter( "filename", buf))
      if (!getMediaParameter( "name", buf))
          buf = "save0000";
          bGenerated = true;
devinfo/rfc2231_notes.txt · Last modified: 28.09.2007 23:02 by kai
Recent changes RSS feed Driven by DokuWiki