Running the sample server code on Netbeans v8.1 with SoapUI v5.3.0 as the client POSTing to http://localhost:8080/, I captured the following response:
HTTP/1.1 200 OK
Date: Mon, 05 Jun 2017 13:53:45 GMT
Server: Test/1.1
Content-Length: 1346189
Connection: Keep-Alive
--5jYQHJoJgT65jloprnB-7ULf3gwvUZ-omC
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/envelope/";>
<soapenv:Header/>
<soapenv:Body>
<AResponse>
<ResponseFile>random.png.gz</ResponseFile>
</AResponse>
</soapenv:Body>
</soapenv:Envelope>
--5jYQHJoJgT65jloprnB-7ULf3gwvUZ-omC
Content-Disposition: form-data; name="random.png.gz";
filename="random.png.gz"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
<snipped data>
--5jYQHJoJgT65jloprnB-7ULf3gwvUZ-omC--
Please note the missing Content-Type HTTP header.
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/envelope/";>;
<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]
> > 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]
smime.p7s
Description: S/MIME cryptographic signature
