Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E0BBB2009A8 for ; Tue, 17 May 2016 21:54:21 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id DF5331609F5; Tue, 17 May 2016 19:54:21 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id DA5A01607A8 for ; Tue, 17 May 2016 21:54:20 +0200 (CEST) Received: (qmail 22078 invoked by uid 500); 17 May 2016 19:54:15 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 21436 invoked by uid 99); 17 May 2016 19:54:15 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 May 2016 19:54:15 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id C14EE180298 for ; Tue, 17 May 2016 19:54:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id q-H9pV3mSHyi for ; Tue, 17 May 2016 19:54:11 +0000 (UTC) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 454EA5F1B3 for ; Tue, 17 May 2016 19:54:11 +0000 (UTC) Received: by mail-wm0-f50.google.com with SMTP id v200so22826926wmv.1 for ; Tue, 17 May 2016 12:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Thsx20aa2rfjBVcdNZLQOtj7BYgzJcBQMpjggIzByvA=; b=yr9pTFCNvY30L9RkIQrlFTXGjjme+pzqcsNfsyAHcvRDmReYS00X2UaO5KzqeGPv+J fORTZrrXgviFiPYJJuBRwcYQofnm10LfVa/VsDOSsUB48w6Vr6AluiWmWDfLTi4D7elh td+aJdag3Iq015yHrgXgBdpV4wBtYrmE4RrHkdGuhwejphRYr+wZDd/1BI9Y9RCksZIM f7Zb/2DStEn7cj9gt48FKTo5EKGGvC/YrPZ852Uk/h84CHc1uR1HcBrFQzh3WRaRerxX I7uFWGQNaHLnNdKlK47qhvkSAo4H8Z8a2pAazudw+1wFkwFLXi8aVnEBpetvtvhGl6Rd KP8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Thsx20aa2rfjBVcdNZLQOtj7BYgzJcBQMpjggIzByvA=; b=gTOT+sFRzLRpoCkQwYfRaun3TGoymq259zpNRZToAASmB4Au+PMDIprKC84B1N9C6s zHOSqFKPHpiY4ujYCGGDQNh+lx2+dbdJUkj27vww2it9HrXZq7nY1aMfjYsl6dEkft/F tUsl1c3aWAVcQdgFtYZ17ohU1i9d3z/WQFaebzyukwH6yX+rH3krE6TEVlKKA1wzbQoG /PAo5X+yKsCMQtkdnvDH0VBkk2q8R25Rd75a8vjXi9LoFsNHhmhJzslCJazeuSLtjNoZ M6Vm01QpQqfsHtoKtAAkwgeBSL5sIxaDInUYLy1ln3rXqKH5TYo/DCBZN1HNX2qEwYx8 3dKA== X-Gm-Message-State: AOPr4FUBbpIIjl6fWGEqNn/ublDrxFT5eC6d6LDZdEBtUS4UDOqj4WsRvftdwwIWT1pkeA== X-Received: by 10.28.175.83 with SMTP id y80mr3226801wme.8.1463514844364; Tue, 17 May 2016 12:54:04 -0700 (PDT) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id ib1sm4758374wjb.48.2016.05.17.12.54.03 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 12:54:03 -0700 (PDT) Subject: Re: CXF 3.1.6 - Headers Added MessageBodyWriter Don't Appear to be Flushed Before OutputStream To: users@cxf.apache.org References: <573B026F.2080106@gmail.com> <573B16C1.80006@gmail.com> <573B3155.8040706@gmail.com> From: Sergey Beryozkin Message-ID: <573B76DA.6010006@gmail.com> Date: Tue, 17 May 2016 20:54:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit archived-at: Tue, 17 May 2016 19:54:22 -0000 Hi Andrey On 17/05/16 16:52, Andrei Shakirin wrote: > Interesting, > > IEFT spec said that quoted-string is used for file names containing spaces: https://tools.ietf.org/html/rfc6266#section-5 > > @Sergei: do you think it is client code or CXF responsibility to check that? > I'd say it the responsibility of the client code to make it understood by all the browsers. Having CXF enforcing the correct values for certain headers can be problematic. Even technically challenging as in this case - we'd need to intercept all the map header writes (when they are done from inside MBW.writeTo()). But while I can imagine it can be done I'd rather not have CXF going into it :-). One recent example. Cookie value with spaces needs to be double-quoted. As it happens the latest session spec says that all the Cookie attributes (besides the value), such as Path, etc, need to be double-quoted if they contain special chars, it even gives the example, such as "Path=a/b", where '/' is a special char, ignoring the fact that '/' is not a special one for a (URI) Path component. So the issue was opened and this is what was done (with the best intentions). Next day after a release (or may the week :-)) we had an issue opened that Firefox was ignoring a double-quoted Path making their application expecting the cookies available at certain Paths non-functional. So the tweak was needed to be applied. Thanks, Sergey > Regards, > Andrei. > >> -----Original Message----- >> From: Christopher Gardner [mailto:chris.r.gardner@gmail.com] >> Sent: Dienstag, 17. Mai 2016 17:32 >> To: users@cxf.apache.org >> Subject: Re: CXF 3.1.6 - Headers Added MessageBodyWriter Don't Appear to >> be Flushed Before OutputStream >> >> Sergey, >> >> Thanks for the suggestion. I found the following: >> >> http://stackoverflow.com/questions/9154415/firefox-and-content- >> disposition-header >> >> Someone on that thread said he or she used double quotes around the file >> name. This now works for me. >> >> Thanks for your help. >> >> On Tue, May 17, 2016 at 10:57 AM, Sergey Beryozkin >> >> wrote: >> >>> Which confirms the headers are being reported properly. >>> >>> You might want to check if there are some known restrictions in the >>> way Firefox treats Content-Disposition, etc >>> >>> Sergey >>> >>> On 17/05/16 15:36, Christopher Gardner wrote: >>> >>>> For both FF and Chrome, I see the following in the trace utility. >>>> >>>> HTTP/1.1 200 OK >>>> Server: Apache-Coyote/1.1 >>>> Date: Tue, 17 May 2016 14:25:26 GMT >>>> Content-Disposition: attachment; filename=My_Report.xlsx >>>> Content-Type: >>>> application/vnd.openxmlformats-officedocument.spreadsheetml.sheet >>>> Transfer-Encoding: chunked >>>> >>>> On Tue, May 17, 2016 at 9:04 AM, Sergey Beryozkin >>>> >>>> wrote: >>>> >>>> Hi >>>>> On 17/05/16 13:50, Christopher Gardner wrote: >>>>> >>>>> Sergey, >>>>>> >>>>>> To answer your questions: >>>>>> >>>>>> * Can you try writing a very small payload, few bytes, and see if >>>>>> the browser prompts ? >>>>>> I tested this in Firefox, which prompted me to save the file with a >>>>>> default file name (not the one the web service added to Content >>>>>> Disposition). >>>>>> However, today I tested in Chrome, which prompted me to save the >>>>>> file name with the one that web service added to Content >>>>>> Disposition. >>>>>> >>>>>> Right, so that does confirm that the header is reported back. >>>>>> >>>>> >>>>> * Are you modifying the headers earlier before MBW gets the control ? >>>>> >>>>>> I'm not explicitly modifying the headers before MBW gets control. >>>>>> My method signature and annotations look like this: >>>>>> >>>>>> @GET >>>>>> @Path("{id}/content") >>>>>> >>>>>> >>>>>> @Produces("application/vnd.openxmlformats- >> officedocument.spreadshee >>>>>> tml.sheet") public Response downloadContent(@PathParam("id") >> Long >>>>>> id) { ... >>>>>> } >>>>>> >>>>>> OK >>>>>> >>>>> >>>>> * Any chance you can get a basic Maven project created so that I can >>>>> drop >>>>>> a >>>>>> war into Tomcat and try to reproduce ? >>>>>> I'll try to work on that. >>>>>> >>>>>> Thanks, lets try to figure out first why different browsers are >>>>>> acting >>>>>> >>>>> differently, to save you some time >>>>> >>>>> In the meantime, I'm still wondering about the difference in >>>>> behavior >>>>>> with >>>>>> Firefox, which does prompt, but doesn't offer the file name at the >>>>>> time of prompting, and Chrome, which behaves properly. >>>>>> >>>>>> Perhaps due to the fact that Content-Disposition is not really a >>>>> top-level >>>>> HTTP response header, it is meant to accompany the individual part, >>>>> inside the actual multipart payload. May be this is why Firefox >>>>> ignores it, while Chrome does not. >>>>> >>>>> Can you try the following check: >>>>> >>>>> start a tcp trace utility which will listen say on 9001 (and >>>>> redirect to >>>>> 9000 - the real service port), and update the form to submit via >>>>> 9001, and check in the tcp trace what is coming back, which headers >>>>> are set. Or may be enable Firefox and Chrome debug mode and see >>>>> which headers came back there... >>>>> >>>>> Let me know what you find please >>>>> >>>>> Cheers, Sergey >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, May 17, 2016 at 7:37 AM, Sergey Beryozkin >>>>> >>>>>> wrote: >>>>>> >>>>>> I have updated the existing test: >>>>>> >>>>>>> >>>>>>> http://git-wip-us.apache.org/repos/asf/cxf/commit/e2fb0483 >>>>>>> >>>>>>> and all works as expected: the two headers set in MBW are >>>>>>> available to the client. >>>>>>> >>>>>>> I wonder why it does not work in your case. >>>>>>> Can you try writing a very small payload, few bytes, and see if >>>>>>> the browser prompts ? >>>>>>> Are you modifying the headers earlier before MBW gets the control ? >>>>>>> Any chance you can get a basic Maven project created so that I can >>>>>>> drop a war into Tomcat and try to reproduce ? >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 16/05/16 23:55, Christopher Gardner wrote: >>>>>>> >>>>>>> I'm writing a large object in MessageBodyWriter.writeTo(). Before >>>>>>> I copy >>>>>>> >>>>>>>> the object to the OutputStream parameter, I set an additional >>>>>>>> http header on the MultiValuedMap parameter. This additional >>>>>>>> header is "Content-Disposition" with an example value of >>>>>>>> "attachment; filename=My_Report.xlsx". The example code looks >>>>>>>> something like: >>>>>>>> >>>>>>>> Representation representation = ... >>>>>>>> httpHeaders.add("Content-Disposition", >>>>>>>> contentDispositionValue(representation.fileName())); >>>>>>>> try { >>>>>>>> >>>>>>>> IOUtils.copyLarge(representation.content(), >>>>>>>> entityOutputStream); >>>>>>>> } catch (Exception e) { >>>>>>>> ... >>>>>>>> } >>>>>>>> >>>>>>>> Note this is all within a Hibernate transaction. The >>>>>>>> Representation object is contains a file name and a Blob. >>>>>>>> Representation.content() calls Blob.getBinaryStream(). >>>>>>>> >>>>>>>> In the browser, I'm prompted to download the content (in this >>>>>>>> case an excel file), but the file name is unknown. However, the >>>>>>>> application log does show that the response includes the content >>>>>>>> disposition. >>>>>>>> >>>>>>>> Now say if I hard code the content-disposition value as in this code: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> Response.ok(myObjectThatGetsMarshalledViaMessageBodyWriter).heade >>>>>>>> r("Content-Disposition", "attachment; filename=foo.xlsx").build() >>>>>>>> >>>>>>>> >>>>>>>> The browser now knows the file name (fool.xlsx). >>>>>>>> "myObjectThatGetsMarshalledViaMessageBodyWriter" is the >> same >>>>>>>> code that I have above. >>>>>>>> >>>>>>>> The javadoc for MessageBodyWriter.writeTo() states: >>>>>>>> >>>>>>>> "The message header map is mutable but any changes must be >> made >>>>>>>> before writing to the output stream since the headers will be >>>>>>>> flushed prior to writing the message body." >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> http://docs.oracle.com/javaee/7/api/javax/ws/rs/ext/MessageBodyWr >>>>>>>> iter.html#writeTo-T-java.lang.Class-java.lang.reflect.Type-java.l >>>>>>>> ang.annotation.Annotation:A-javax.ws.rs.core.MediaType- >> javax.ws.r >>>>>>>> s.core.MultivaluedMap-java.io.OutputStream- >>>>>>>> >>>>>>>> Is there anything I can do to ensure the header value created >>>>>>>> within >>>>>>>> MessageBodyWriter.writeTo() is seen before the body is? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Sergey Beryozkin >>>>>>> >>>>>>> Talend Community Coders >>>>>>> http://coders.talend.com/ >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> -- >>>>> Sergey Beryozkin >>>>> >>>>> Talend Community Coders >>>>> http://coders.talend.com/ >>>>> >>>>> >>>> >>> >>> -- >>> Sergey Beryozkin >>> >>> Talend Community Coders >>> http://coders.talend.com/ >>> -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/