Skip Menu |

This queue is for tickets about the MIME-tools CPAN distribution.

Report information
The Basics
Id: 79356
Status: open
Priority: 0/
Queue: MIME-tools

People
Owner: dfs+pause [...] roaringpenguin.com
Requestors: john.softek [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Request to use mime attribute content-location to determine recommended filename
Date: Sun, 2 Sep 2012 22:34:38 +1000
To: bug-MIME-tools [...] rt.cpan.org
From: John Murphy <john.softek [...] gmail.com>
Hi, RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) provides a means of specifying the name and location of an attachment. This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. Example: ----=_rsvp_irot_part_1311710291l.0xabe91c30 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Location: genImages/attach_1.gif You could accommodate this convention by changing this line in sub recommended_filename in Head.pm from: foreach my $attr_name ( qw( content-disposition.filename content-type.name) ) { to: foreach my $attr_name ( qw( content-disposition.filename content-type.namecontent-location) ) { Regards, John Murphy
Subject: Re: [rt.cpan.org #79356] Request to use mime attribute content-location to determine recommended filename
Date: Tue, 4 Sep 2012 11:19:08 -0400
To: bug-MIME-tools [...] rt.cpan.org
From: "David F. Skoll" <dfs [...] roaringpenguin.com>
On Sun, 2 Sep 2012 08:34:49 -0400 "John Murphy via RT" <bug-MIME-tools@rt.cpan.org> wrote: Show quoted text
> RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML > (MHTML) provides a means of specifying the name and location of an > attachment.
Right, but the value of the Content-Location: header is a URI. I'm not sure it's safe to parse a filename out of a URI the same way it's parsed out of the other headers. I think additional code will be needed. Regards, David.
Subject: Re: [rt.cpan.org #79356] Request to use mime attribute content-location to determine recommended filename
Date: Wed, 5 Sep 2012 10:09:12 +1000
To: bug-MIME-tools [...] rt.cpan.org
From: John Murphy <john.softek [...] gmail.com>
David, I mainly want the original file name, not its location. When the file is saved, the path is stripped from the recommended filename, which is exactly what I want. It's much better than several hundred files all named msg... John M On 5 September 2012 01:19, David F. Skoll via RT <bug-MIME-tools@rt.cpan.org Show quoted text
> wrote:
Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=79356 > > > On Sun, 2 Sep 2012 08:34:49 -0400 > "John Murphy via RT" <bug-MIME-tools@rt.cpan.org> wrote: >
> > RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML > > (MHTML) provides a means of specifying the name and location of an > > attachment.
> > Right, but the value of the Content-Location: header is a URI. I'm > not sure it's safe to parse a filename out of a URI the same way > it's parsed out of the other headers. I think additional code will > be needed. > > Regards, > > David. > >