On Mon, 2017-06-05 at 14:39 +0000, Dan Wlodarski wrote: > Running the sample server code on Netbeans v8.1 with SoapUI v5.3.0 as
... > > > Please note the missing Content-Type HTTP header. > Did you set a Content-Type header on the response entity? Oleg > The Content-Type header is also missing from the response in my own > curl > v7.53.0 tests. > > The additional testing and verification is appreciated. > > -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Monday, June 5, 2017 10:15 > To: HttpClient User Discussion <[email protected]> > Subject: Re: Cannot transmit a SWA response with a large attachment > (HttpEntity can't chunk multipart) > > On Mon, 2017-06-05 at 14:07 +0000, Dan Wlodarski wrote: > > I've tried that solution previously. The result is a missing > > initial > > HTTP header. The transmission begins at the MIME multipart border. > > > > I see no evidence supporting this assertion. > > Oleg > > --- > oleg@ok2c:~$ curl -X POST http://localhost:8080/ -v > * Trying ::1... > * TCP_NODELAY set > * Connected to localhost (::1) port 8080 (#0) > > POST / HTTP/1.1 > > Host: localhost:8080 > > User-Agent: curl/7.52.1 > > Accept: */* > > > > < HTTP/1.1 200 OK > < Date: Mon, 05 Jun 2017 14:13:23 GMT > < Server: Test/1.1 > < Content-Length: 678 > < Content-Type: multipart/form-data; > boundary=PLjXq6xrj2ONaDdnyMPLBEnpkMqZA9Wmjw23 > < > --PLjXq6xrj2ONaDdnyMPLBEnpkMqZA9Wmjw23 > Content-Disposition: form-data; name="SOAP Envelope" > Content-Type: application/xml; charset=ISO-8859-1 > Content-Transfer-Encoding: 8bit > > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/enve > lope/">;; > <soapenv:Header/> > <soapenv:Body> > <AResponse> > <ResponseFile>/home/oleg/blah.txt</ResponseFile> > </AResponse> > </soapenv:Body> > </soapenv:Envelope> > --PLjXq6xrj2ONaDdnyMPLBEnpkMqZA9Wmjw23 > Content-Disposition: form-data; name="/home/oleg/blah.txt"; > filename="blah.txt" > Content-Type: application/octet-stream > Content-Transfer-Encoding: binary > > blah > > --PLjXq6xrj2ONaDdnyMPLBEnpkMqZA9Wmjw23-- > * Curl_http_done: called premature == 0 > * Connection #0 to host localhost left intact > --- > > > Pastebin source (https://pastebin.com/2Hzdhpt3) has been updated > > for > > further error replication. > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:[email protected]] > > Sent: Monday, June 5, 2017 07:14 > > To: HttpClient User Discussion <[email protected]> > > Subject: Re: Cannot transmit a SWA response with a large attachment > > (HttpEntity can't chunk multipart) > > > > On Sun, 2017-06-04 at 15:03 +0000, Dan Wlodarski wrote: > > > To whom it may concern: > > > > > > Issue: HttpClient API does not support chunking multipart > > > HttpEntities. > > > Clients making SOAP requests to a mock SOAP with attachments > > > (SWA) > > > server are failing (specifically, Apache-based Java clients are > > > throwing > > > org.apache.http.NoHttpResponseExceptions) when the attachment in > > > the > > > response is large (>2 MiB). Small attachments are transmitted > > > without throwing any exceptions. HTTP Content-Length header is > > > correct. > > > > > > Use case: Multithreaded SOAP server capable of transmitting SWA > > > responses of arbitrary content length > > > > > > Libraries: HttpCore v4.4.6 + HttpMime v4.5.3 > > > > > > Example server source for error replication is available at: > > > https://pastebin.com/2Hzdhpt3 > > > > > > Error replication: > > > 1. Build the above source with HttpCore v4.4.6 and HttpMime > > > v4.5.3 > > > libraries (HttpMime is part of the HttpClient project). > > > 2. Run the program with a sufficiently large (>2 MiB) binary file > > > named "random.png.gz" with correct pathing and permissions (a > > > readable directory sibling of the executable). > > > 3. Send the server an arbitrary HTTP POST request via some third- > > > party client. Note the failure to receive the large server- > > > generated multipart result. > > > > > > NB: SoapUI can be leveraged as an Apache-based Java client with > > > precision logging. > > > > > > Please advise. > > > > > > > Dan, > > > > You are mixing up non-blocking i/o transport and a blocking i/o > > entity > > implementation. This is generally a bad idea as it cannot be done > > efficiently without full or partial content buffering in memory. > > > > If do not mind buffering the entire entity in memory, you can > > replace > > --- > > response.setEntity(responseEntity); > > --- > > > > with > > > > --- > > final ByteArrayOutputStream out = new ByteArrayOutputStream(); > > responseEntity.writeTo(out); response.setEntity(new > > ByteArrayEntity(out.toByteArray())); > > --- > > > > and your code will work just fine. > > > > Oleg > > > > > > > Thanks, > > > > > > Dan C. Wlodarski > > > The Design Knowledge Company > > > 3100 Presidential Drive > > > Suite 103 > > > Fairborn, Ohio 45324 > > > > > > Phone: 937-427-4276 x175 > > > Fax: 937-427-1242 > > > [email protected] > > > www.tdkc.com > > > > > > P.S. This issue was originally submitted on 30 May, but did not > > > appear in the archives. Assumed dropped. > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: [email protected] > > > g > > > For additional commands, e-mail: [email protected]. > > > or > > > g > > > > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > g > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
