You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Piotr Skawinski <pi...@gmail.com> on 2011/11/02 16:04:10 UTC
Different behaviours with MultipartBody (REST) in different browsers
Hi,
I'm facing different behaviours with MultipartBody on REST services. When
using MultipartBody as a return value on a service method annotated with
jax-rs annotation like:
@GET
@Path("/downloadFile/{ticket}/{fileId}")
@Produces("multipart/mixed")
MultipartBody downloadFile(@PathParam("ticket") String
ticket, @PathParam("fileId") String fileId) throws IOException;
Internet Explorer cannot download the file being included in MultipartBody
correctly, but shows only the binary content of MultipartBody (the file
being included in it). Chrome and Safari is downloading the content of the
file nicely, but is not showing the file name that is specified as:
MultipartBody multipartBody = new MultipartBody(new Attachment("eclosure",
new FileInputStream(file),
new ContentDisposition("attachment;filename=" +
fileInfo.getFileNameWithCpr())));
Only the Fifefox is downloading the file as expected.
Any help will be appriciated.
Piotr
Re: Different behaviours with MultipartBody (REST) in different browsers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi, Did you have any progress on this issue ?
FYI, I can see that MultipartProvider initializes Content-Disposition
like this: "form-data;name=file;filename=" + f.getName()" - in case of
multipart/form-data...
Sergey
On 03/11/11 10:13, Sergey Beryozkin wrote:
> Hi Piotr
>
> On 03/11/11 09:11, Piotr Skawinski wrote:
>> Hi Sergey,
>>
>> Thanks for reply :)
>>
>> Using multipart/form-data is not solving the problem and firefox now
>> downloads the file as some default name and not as one specified in
>> ContentDisposition("**attachment;filename=myfilename.pdf"). The IE is
>> still
>> only showing the binary content in the browser. I can do some work around
>> to get it work with IE and to get it show the content of the file in the
>> browser by doing something like that in the service method declaration:
>>
>> @GET
>> @Path("/downloadFile/{ticket}/{fileId}")
>> Response downloadFile(@PathParam("ticket") String ticket,
>> @PathParam("fileId") String fileId) throws IOException;
>>
>> and in the implementation by doing something like that:
>>
>> return Response.ok(new FileInputStream(file))
>> .header("Content-type", "application/pdf")
>> .build();
>>
>> but then the browsers (all of them) is not offering (in a download popup)
>> to save the file in the file system.
>
> Yes - that what we want really when returning a multipart body, please
> add a resource method which actually accepts it:
> @Consumes({"multipart/form-data", "multipart/mixed"})
> public void upload(MultipartBody body) {}
>
> and add LoggingInInterceptor
>
> and try uploading a small binary file from every browser - that should
> give a better idea of how each of them structures a multipart payload
> and hence what they expect.
> Adding "Content-Encoding: binary" or similar may help IE not to show the
> binary content, while experimenting a bit the content of
> Content-Disposition may help Chrome and Safari to show the file name
> properly,
>
> I'm interested to see how it goes, please keep me updated :-)
> Thanks, Sergey
>
>>
>> Piotr
>>
>>
>>
>>
>>
>> On Wed, Nov 2, 2011 at 7:11 PM, Sergey
>> Beryozkin<sb...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>>
>>> On 02/11/11 15:04, Piotr Skawinski wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm facing different behaviours with MultipartBody on REST services.
>>>> When
>>>> using MultipartBody as a return value on a service method annotated
>>>> with
>>>> jax-rs annotation like:
>>>>
>>>> @GET
>>>> @Path("/downloadFile/{ticket}/**{fileId}")
>>>> @Produces("multipart/mixed")
>>>> MultipartBody downloadFile(@PathParam("**ticket") String
>>>> ticket, @PathParam("fileId") String fileId) throws IOException;
>>>>
>>>> Internet Explorer cannot download the file being included in
>>>> MultipartBody
>>>> correctly, but shows only the binary content of MultipartBody (the file
>>>> being included in it). Chrome and Safari is downloading the content
>>>> of the
>>>> file nicely, but is not showing the file name that is specified as:
>>>>
>>>> MultipartBody multipartBody = new MultipartBody(new
>>>> Attachment("eclosure",
>>>> new FileInputStream(file),
>>>> new ContentDisposition("**attachment;filename=" +
>>>> fileInfo.getFileNameWithCpr())**));
>>>>
>>>> Only the Fifefox is downloading the file as expected.
>>>>
>>>> Any help will be appriciated.
>>>>
>>>> thanks for this info, if it were possible to somehow compare the
>>> payloads returned from CXF against some similar payloads from some other
>>> services then it would probably help, I guess I can try that too but
>>> a bit
>>> later.
>>> But then Firefox did manage to get it right, so...
>>> Actually, could it be that other browsers don;t like
>>> "multipart/mixed" and
>>> expect "multipart/form-data" ? Can you try it please ?
>>>
>>> Cheers, Sergey
>>>
>>> Piotr
>>>>
>>>>
>>>
>>
>
Re: Different behaviours with MultipartBody (REST) in different browsers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Piotr
On 03/11/11 09:11, Piotr Skawinski wrote:
> Hi Sergey,
>
> Thanks for reply :)
>
> Using multipart/form-data is not solving the problem and firefox now
> downloads the file as some default name and not as one specified in
> ContentDisposition("**attachment;filename=myfilename.pdf"). The IE is still
> only showing the binary content in the browser. I can do some work around
> to get it work with IE and to get it show the content of the file in the
> browser by doing something like that in the service method declaration:
>
> @GET
> @Path("/downloadFile/{ticket}/{fileId}")
> Response downloadFile(@PathParam("ticket") String ticket,
> @PathParam("fileId") String fileId) throws IOException;
>
> and in the implementation by doing something like that:
>
> return Response.ok(new FileInputStream(file))
> .header("Content-type", "application/pdf")
> .build();
>
> but then the browsers (all of them) is not offering (in a download popup)
> to save the file in the file system.
Yes - that what we want really when returning a multipart body, please
add a resource method which actually accepts it:
@Consumes({"multipart/form-data", "multipart/mixed"})
public void upload(MultipartBody body) {}
and add LoggingInInterceptor
and try uploading a small binary file from every browser - that should
give a better idea of how each of them structures a multipart payload
and hence what they expect.
Adding "Content-Encoding: binary" or similar may help IE not to show the
binary content, while experimenting a bit the content of
Content-Disposition may help Chrome and Safari to show the file name
properly,
I'm interested to see how it goes, please keep me updated :-)
Thanks, Sergey
>
> Piotr
>
>
>
>
>
> On Wed, Nov 2, 2011 at 7:11 PM, Sergey Beryozkin<sb...@gmail.com>wrote:
>
>> Hi,
>>
>>
>> On 02/11/11 15:04, Piotr Skawinski wrote:
>>
>>> Hi,
>>>
>>> I'm facing different behaviours with MultipartBody on REST services. When
>>> using MultipartBody as a return value on a service method annotated with
>>> jax-rs annotation like:
>>>
>>> @GET
>>> @Path("/downloadFile/{ticket}/**{fileId}")
>>> @Produces("multipart/mixed")
>>> MultipartBody downloadFile(@PathParam("**ticket") String
>>> ticket, @PathParam("fileId") String fileId) throws IOException;
>>>
>>> Internet Explorer cannot download the file being included in MultipartBody
>>> correctly, but shows only the binary content of MultipartBody (the file
>>> being included in it). Chrome and Safari is downloading the content of the
>>> file nicely, but is not showing the file name that is specified as:
>>>
>>> MultipartBody multipartBody = new MultipartBody(new Attachment("eclosure",
>>> new FileInputStream(file),
>>> new ContentDisposition("**attachment;filename=" +
>>> fileInfo.getFileNameWithCpr())**));
>>>
>>> Only the Fifefox is downloading the file as expected.
>>>
>>> Any help will be appriciated.
>>>
>>> thanks for this info, if it were possible to somehow compare the
>> payloads returned from CXF against some similar payloads from some other
>> services then it would probably help, I guess I can try that too but a bit
>> later.
>> But then Firefox did manage to get it right, so...
>> Actually, could it be that other browsers don;t like "multipart/mixed" and
>> expect "multipart/form-data" ? Can you try it please ?
>>
>> Cheers, Sergey
>>
>> Piotr
>>>
>>>
>>
>
Re: Different behaviours with MultipartBody (REST) in different browsers
Posted by Piotr Skawinski <pi...@gmail.com>.
Hi Sergey,
Thanks for reply :)
Using multipart/form-data is not solving the problem and firefox now
downloads the file as some default name and not as one specified in
ContentDisposition("**attachment;filename=myfilename.pdf"). The IE is still
only showing the binary content in the browser. I can do some work around
to get it work with IE and to get it show the content of the file in the
browser by doing something like that in the service method declaration:
@GET
@Path("/downloadFile/{ticket}/{fileId}")
Response downloadFile(@PathParam("ticket") String ticket,
@PathParam("fileId") String fileId) throws IOException;
and in the implementation by doing something like that:
return Response.ok(new FileInputStream(file))
.header("Content-type", "application/pdf")
.build();
but then the browsers (all of them) is not offering (in a download popup)
to save the file in the file system.
Piotr
On Wed, Nov 2, 2011 at 7:11 PM, Sergey Beryozkin <sb...@gmail.com>wrote:
> Hi,
>
>
> On 02/11/11 15:04, Piotr Skawinski wrote:
>
>> Hi,
>>
>> I'm facing different behaviours with MultipartBody on REST services. When
>> using MultipartBody as a return value on a service method annotated with
>> jax-rs annotation like:
>>
>> @GET
>> @Path("/downloadFile/{ticket}/**{fileId}")
>> @Produces("multipart/mixed")
>> MultipartBody downloadFile(@PathParam("**ticket") String
>> ticket, @PathParam("fileId") String fileId) throws IOException;
>>
>> Internet Explorer cannot download the file being included in MultipartBody
>> correctly, but shows only the binary content of MultipartBody (the file
>> being included in it). Chrome and Safari is downloading the content of the
>> file nicely, but is not showing the file name that is specified as:
>>
>> MultipartBody multipartBody = new MultipartBody(new Attachment("eclosure",
>> new FileInputStream(file),
>> new ContentDisposition("**attachment;filename=" +
>> fileInfo.getFileNameWithCpr())**));
>>
>> Only the Fifefox is downloading the file as expected.
>>
>> Any help will be appriciated.
>>
>> thanks for this info, if it were possible to somehow compare the
> payloads returned from CXF against some similar payloads from some other
> services then it would probably help, I guess I can try that too but a bit
> later.
> But then Firefox did manage to get it right, so...
> Actually, could it be that other browsers don;t like "multipart/mixed" and
> expect "multipart/form-data" ? Can you try it please ?
>
> Cheers, Sergey
>
> Piotr
>>
>>
>
Re: Different behaviours with MultipartBody (REST) in different browsers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Some more possible approaches to making it work consistently:
- try adding a Content-Encoding header to an attachment
- make all browsers upload the binary file to the server and check how
each individual browser sets the headers such as Content-Type and
Content-Disposition of individual parts...
Let us know how it goes please
Sergey
On 02/11/11 18:11, Sergey Beryozkin wrote:
> Hi,
>
> On 02/11/11 15:04, Piotr Skawinski wrote:
>> Hi,
>>
>> I'm facing different behaviours with MultipartBody on REST services. When
>> using MultipartBody as a return value on a service method annotated with
>> jax-rs annotation like:
>>
>> @GET
>> @Path("/downloadFile/{ticket}/{fileId}")
>> @Produces("multipart/mixed")
>> MultipartBody downloadFile(@PathParam("ticket") String
>> ticket, @PathParam("fileId") String fileId) throws IOException;
>>
>> Internet Explorer cannot download the file being included in
>> MultipartBody
>> correctly, but shows only the binary content of MultipartBody (the file
>> being included in it). Chrome and Safari is downloading the content of
>> the
>> file nicely, but is not showing the file name that is specified as:
>>
>> MultipartBody multipartBody = new MultipartBody(new
>> Attachment("eclosure",
>> new FileInputStream(file),
>> new ContentDisposition("attachment;filename=" +
>> fileInfo.getFileNameWithCpr())));
>>
>> Only the Fifefox is downloading the file as expected.
>>
>> Any help will be appriciated.
>>
> thanks for this info, if it were possible to somehow compare the
> payloads returned from CXF against some similar payloads from some other
> services then it would probably help, I guess I can try that too but a
> bit later.
> But then Firefox did manage to get it right, so...
> Actually, could it be that other browsers don;t like "multipart/mixed"
> and expect "multipart/form-data" ? Can you try it please ?
>
> Cheers, Sergey
>
>> Piotr
>>
>
Re: Different behaviours with MultipartBody (REST) in different browsers
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 02/11/11 15:04, Piotr Skawinski wrote:
> Hi,
>
> I'm facing different behaviours with MultipartBody on REST services. When
> using MultipartBody as a return value on a service method annotated with
> jax-rs annotation like:
>
> @GET
> @Path("/downloadFile/{ticket}/{fileId}")
> @Produces("multipart/mixed")
> MultipartBody downloadFile(@PathParam("ticket") String
> ticket, @PathParam("fileId") String fileId) throws IOException;
>
> Internet Explorer cannot download the file being included in MultipartBody
> correctly, but shows only the binary content of MultipartBody (the file
> being included in it). Chrome and Safari is downloading the content of the
> file nicely, but is not showing the file name that is specified as:
>
> MultipartBody multipartBody = new MultipartBody(new Attachment("eclosure",
> new FileInputStream(file),
> new ContentDisposition("attachment;filename=" +
> fileInfo.getFileNameWithCpr())));
>
> Only the Fifefox is downloading the file as expected.
>
> Any help will be appriciated.
>
thanks for this info, if it were possible to somehow compare the
payloads returned from CXF against some similar payloads from some other
services then it would probably help, I guess I can try that too but a
bit later.
But then Firefox did manage to get it right, so...
Actually, could it be that other browsers don;t like "multipart/mixed"
and expect "multipart/form-data" ? Can you try it please ?
Cheers, Sergey
> Piotr
>