Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mfncooper@gmail.com designates
 64.233.162.201 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references;
        b=MX6TOKzoRUuo28eNcGpEXlXA4lCpz6P1jjFXZci7/Huw6MAeJBs+a2Y5aUyUKaAlNolhAujJeE4ATaumaAxrwVpBpwKe6duoSXawYSR5wPHZExcMbyaFMz1XCNU/iQXWtay/nOwGEAVTfS0kaWHlzvazkq3ti0HfFwzObJ+sAok=
Message-ID: <16d6c6200602082229u43509273rf532aac650d7e61f@mail.gmail.com>
Date: Wed, 8 Feb 2006 22:29:56 -0800
From: Martin Cooper <martinc@apache.org>
Sender: mfncooper@gmail.com
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: Many attachments, one name
In-Reply-To: <a30d97d10602081107g21fc7c1ax3426c7f5aeda673e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2259_22102078.1139466596730"
References: <a30d97d10602080921x22cfc8e0n69d00c3de814fb19@mail.gmail.com>
	 <16d6c6200602081033n93ba881p8b86a27e01529988@mail.gmail.com>
	 <a30d97d10602081107g21fc7c1ax3426c7f5aeda673e@mail.gmail.com>

------=_Part_2259_22102078.1139466596730
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 2/8/06, Greg Evetts <greg@evetts.org> wrote:
>
> It seems to me that the bug is the failure to persist the field name
> ("pics" in this example) and apply it to subsequent attachments within
> this multipart/mixed segment.  I think that to overload the "filename"
> by giving it "field name" semantics is incorrect.


Sorry, yes, you're right. Please file a bug report in Bugzilla to make sure
this doesn't get lost.

To answer your question regarding the client-side, I've written an
> applet generates the request. I can send you the source if you're
> interested.


Yes please. That would be very helpful. Thanks!

--
Martin Cooper


-Greg Evetts
>
> On 2/8/06, Martin Cooper <martinc@apache.org> wrote:
> > On 2/8/06, Greg Evetts <greg@evetts.org> wrote:
> > >
> > > I'm having a problem parsing this example multipart request from RFC
> > > 1867. It appears that the attachmements "file1.txt" and "file2.gif"
> > > are associates with the same form field name, "pics". However, since
> > > the name "pics" is specified in the content-disposition header on lin=
e
> > > [08], it is lost when the content-disposition header on line [12] is
> > > parsed. The attachment is returned in the FileItem but the fieldName
> > > property is null.
> >
> >
> > There are two separate issues here. The first is that FileUpload will
> only
> > retain the name of individual items, and not the collective name given
> to
> > multipart/mixed data, so you should not expect "pics" to show up
> anywhere in
> > the results. The second issue is that FileUpload is not picking up the
> > filename from an attachment as the field name. That's probably a bug, s=
o
> it
> > would be good if you could file a bug report against it in Bugzilla.
> >
> > To be honest, the whole multipart/mixed thing hardly ever comes up, and
> so
> > hasn't had much attention paid to it. Can you tell me how you generated
> the
> > request that you're trying to parse?
> >
> > --
> > Martin Cooper
> >
> >
> > [01] Content-type: multipart/form-data, boundary=3DAaB03x
> > > [02]
> > > [03] --AaB03x
> > > [04] content-disposition: form-data; name=3D"field1"
> > > [05]
> > > [06] Joe Blow
> > > [07] --AaB03x
> > > [08] content-disposition: form-data; name=3D"pics"
> > > [09] Content-type: multipart/mixed, boundary=3DBbC04y
> > > [10]
> > > [11] --BbC04y
> > > [12] Content-disposition: attachment; filename=3D"file1.txt"
> > > [13] Content-Type: text/plain
> > > [14]
> > > [15] ... contents of file1.txt ...
> > > [16] --BbC04y
> > > [17] Content-disposition: attachment; filename=3D"file2.gif"
> > > [18] Content-type: image/gif
> > > [19] Content-Transfer-Encoding: binary
> > > [20]
> > > [21] ...contents of file2.gif...
> > > [22] --BbC04y--
> > > [23] --AaB03x--
> > >
> > > Here's the code I'm using to parse the request:
> > >
> > > [01] final FileItemFactory factory =3D new DiskFileItemFactory(1024,
> > > TMPDIR);
> > > [02] final ServletFileUpload upload =3D new ServletFileUpload(factory=
);
> > > [03]
> > > [04] upload.setSizeMax(1 << 22); // 4MB
> > > [05]
> > > [06] final List<FileItem> items =3D upload.parseRequest(request_);
> > > [07]
> > > [08] for (final FileItem fi : items) {
> > > [09]   final String name =3D fi.getFieldName();
> > > [10]   ...
> > > [11] }
> > >
> > > Any help is appreciated.
> > > -Greg Evetts
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

------=_Part_2259_22102078.1139466596730--