view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

1.014     2007-03-22
        - packaging improvements

1.013     2007-03-20
        - fix significantly broken SYNOPSIS

1.012     2006-11-25
        - allow carp-avoidance through (ugh) package variable; bug 14076

1.011     2006-10-12
        - clearer special case for undef/empty content-type
          (thanks, JESSE!)

1.01
        - typo fix in documentation by John Linderman.
        - new author, Casey West.
        - Fix bug with blank space following parameters.

0.01      Wed Jan  7 17:38:23 2004
        - original version; created by h2xs 1.22 with options
          -AX -b 5.6.0 -n Email::MIME::ContentType

lib/Email/MIME/ContentType.pm  view on Meta::CPAN

#pod This routine is exported by default.
#pod
#pod This routine builds email Content-Disposition header according to RFC 2182 and
#pod RFC 2231.  It takes a hash as above, with entries for the C<type>, and
#pod optionally also a hash of C<attributes>.  It returns a string representing
#pod Content-Disposition header.  Non-ASCII or too long attributes are handled in
#pod the same way like in L<build_content_type function|/build_content_type>.
#pod
#pod =head1 WARNINGS
#pod
#pod This is not a valid content-type header, according to both RFC 1521 and RFC
#pod 2045:
#pod
#pod   Content-Type: type/subtype;
#pod
#pod If a semicolon appears, a parameter must.  C<parse_content_type> will carp if
#pod it encounters a header of this type, but you can suppress this by setting
#pod C<$Email::MIME::ContentType::STRICT_PARAMS> to a false value.  Please consider
#pod localizing this assignment!
#pod
#pod Same applies for C<parse_content_disposition>.

lib/Email/MIME/ContentType.pm  view on Meta::CPAN

This routine is exported by default.

This routine builds email Content-Disposition header according to RFC 2182 and
RFC 2231.  It takes a hash as above, with entries for the C<type>, and
optionally also a hash of C<attributes>.  It returns a string representing
Content-Disposition header.  Non-ASCII or too long attributes are handled in
the same way like in L<build_content_type function|/build_content_type>.

=head1 WARNINGS

This is not a valid content-type header, according to both RFC 1521 and RFC
2045:

  Content-Type: type/subtype;

If a semicolon appears, a parameter must.  C<parse_content_type> will carp if
it encounters a header of this type, but you can suppress this by setting
C<$Email::MIME::ContentType::STRICT_PARAMS> to a false value.  Please consider
localizing this assignment!

Same applies for C<parse_content_disposition>.