cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Different behaviours with MultipartBody (REST) in different browsers
Date Fri, 11 Nov 2011 12:12:04 GMT
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<sberyozkin@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
>>>>
>>>>
>>>
>>
>


Mime
View raw message