I've been running some of the examples for MSF4J. Im looking into creating a service that allows uploading of files, but they are send using multipart/form-data. Our front sends the data with chunked encoding.
So, the FileServer example shows how to handle chunked streams with the HttpStreamer and the Formparam examples show how to handle multipart/form-data. But when I send a chunked request to the /simpleFormStreaming, it doesn't work (get a HTTP 500 response). When sending an non-chunked request (Content-Lenght is set). It does work ok.
So how can I handle a multipart/form-data request that is send using chunked encoding?
Thanks,
Danny
At the moment MSF4J doesn't support chunked data with FormParam. But you can use the HttpStreamer as in FileServer sample.
HttpStreamer.chunk method will get execute for each and every chunk. You need to implement the multipart/form-data handling logic in your HttpStreamHandler implementation. I think you can use commons-file-upload directly and do the processing.
Related
Thank you for the nice work you put into this amazing library.
I have an issue with my request adapter but only with the MultipartFormData.
I want to be able to update the body of the request but when the request gets in the adapter, I'm getting a nil httpBody. I only get this behaviour on Multipart, not on classic POST requests.
I'm trying to sign the request with an oauth2 token (async), but the particularity of this API is that the token is sent in the body and not in the headers.
There's a body as the metrics in the response say (Request Body Transfer Bytes) 231306
I'm using Alamofire 5.0.0
This is most likely due to multipart forms using UploadRequests (and therefore URLSessionUploadTasks) which do not include the body data as part of the URLRequest for performance reasons. If you update your question with what you're trying to do to the body, perhaps I can provide an alternate solution. If nothing else, you could manually create multipart uploads by using MultipartFormData.encode() directly and adding the Data to a URLRequest, but that's not recommended for large uploads.
I'm using spray-can and spray-routing to support a REST service that includes an operation to upload files. This operation accepts multipart/form-data and the formFields directive works well.
When I try to use the spray request chunking support though, I find that the formFields directive is not working as the whole multipart message is chunked and not just the one part that is large.
Has anyone got any advice on how the handle large multipart messages in spray-can?
All I can think of right now is to put the whole request data in a temp file and to use something like org.apache.commons.fileupload.MultipartStream to parse the request.
What type of response listener must we use to handle gzip responses with Android Volley?
If a String listener is used, the response seems to lose its encoding.
How do you handle gzip responses using Volley?
MAJOR EDIT:
HttpUrlConnection automatically adds the gzip header to requests, and if the response is gzipped, it will seamlessly decode it and present to you the response. All the gzip stuff happens behind the scenes and you don't need to do what I posted in a gist as an answer to this question. See the documentation here http://developer.android.com/reference/java/net/HttpURLConnection.html
As a matter of fact, the answer I posted SHOULD NOT be used, because the gzip decoding is extremely slow, and should be left to be handled by HttpUrlConnection.
Here is the exact piece from the documentation:
By default, this implementation of HttpURLConnection requests that
servers use gzip compression. Since getContentLength() returns the
number of bytes transmitted, you cannot use that method to predict how
many bytes can be read from getInputStream(). Instead, read that
stream until it is exhausted: when read() returns -1. Gzip compression
can be disabled by setting the acceptable encodings in the request
header:
urlConnection.setRequestProperty("Accept-Encoding", "identity");
So I figured out how to do this.
Basically, I extended StringRequest so that it handles the network response a different way.
You can just parse the response bytearray using GZipInputStream and return the resultant string.
Here's the gist: https://gist.github.com/premnirmal/8526542
You should use ion ,, it's comes pre-set with
Transparent usage of HTTP features and optimizations:
SPDY and HTTP/2
Caching
Gzip/Deflate Compression
Connection pooling/reuse via HTTP Connection: keep-alive
Uses the best/stablest connection from a server if it has multiple IP addresses
Cookies
I have been writing iPhone applications for some time now, sending data to server, receiving data (via HTTP protocol), without thinking too much about it. Mostly I am theoretically familiar with process, but the part I am not so familiar is HTTP multipart request. I know its basic structure, but the core of it eludes me.
It seems that whenever I am sending something different than plain text (like photos, music), I have to use a multipart request. Can someone briefly explain to me why it is used and what are its advantages?
If I use it, why is it better way to send photos that way?
An HTTP multipart request is an HTTP request that HTTP clients construct to send files and data over to an HTTP Server. It is commonly used by browsers and HTTP clients to upload files to the server.
What it looks like
See Multipart Content-Type
See multipart/form-data
As the official specification says, "one or more different sets of data are combined in a single body". So when photos and music are handled as multipart messages as mentioned in the question, probably there is some plain text metadata associated as well, thus making the request containing different types of data (binary, text), which implies the usage of multipart.
I have found an excellent and relatively short explanation here.
A multipart request is a REST request containing several packed REST requests inside its entity.
I'm trying to use Fiddler to break when the response contains a specific word and edit the response live.
However, it seems that the oSession.utilFindInResponse function does not match successfully because the response is using GZIP encoding.
Is it possible to get around this ?
I'm new to fiddlers rules but there might be a way to change http compression on the fly ?
Thanks
Calling oSession.utilDecodeResponse() on the session object will remove HTTP chunking and compression from the response.