I'm sending multipart/mixed content message from JSP to servlets but when I used
ServletFileUpload.isMultipartContent(request);
method to check if the request is Multipart or not, I'm getting the output as "false". This is how content type header of my message is looking like:
multipart/mixed;
boundary="----=_Part_26_2184190.1271924416255"
Could anyone please tell me how can I parse the request using Apache fileupload API? How the above method can return me an output as "true"
The conditions are:
the request method must be post
the content-type must start with multipart/
Check these two via request.getMethod() and request.getContentType()
Related
Working in a special situation, I must hanldle a request with ConentType:application/x-www-form-urlencoded but not encoded when delivering.
Spring may decoded the request body so I will get a wrong body for eg:
correct string:"a+b+c"
spring decoede ones:"a b c"
I couldn't change the behavior of the guy who posting the method, so I think I need a way to do so as title said:
disbale decode request body in spring handling HTTP POST with header application/x-www-form-urlencoded (or get the original request body)
Can someone help me this, plz...
https://tomcat.apache.org/tomcat-8.0-doc/config/http.html
I changed the params:parseBodyMethods, and now any post http methods won't be parsed anymore.
GET call on REST API with Accept as text/csv and content-Type as application/json. In what format should the reponse be?
Should the response be in JSON format or in CSV format?
In HTTP, the Accept header is used by the client to tell the server what content types they'll accept.
The server will then send back the response and will set the Content-type header telling the client the type of the content actually returned.
You might have noticed that Content-type is also included in some HTTP requests. This is because some type of HTTP requests, like POST or PUT, can send data to the server. In this case the client tells the server the type of the content data, using the Content-type header.
Now to your question, a GET request should not have any Content-type header. I hope this is clear after my explanation above.
As you correctly note, the Accept header is used by HTTP clients to tell the server what content types they'll accept. The server will then send back a response, which will include a Content-Type header telling the client what the content type of the returned content actually is.
However, as you may have noticed, HTTP requests can also contain Content-Type headers. Why? Well, think about POST or PUT requests. With those request types, the client is actually sending a bunch of data to the server as part of the request, and the Content-Type header tells the server what the data actually is (and thus determines how the server will parse it).
In particular, for a POST request resulting from an HTML form submission, the Content-Type of the request will (normally) be one of the standard form content types below, as specified by the enctype attribute on the tag:
application/x-www-form-urlencoded (default, older, simpler, slightly less overhead for small amounts of simple ASCII text, no file upload support)
multipart/form-data (newer, adds support for file uploads, more efficient for large amounts of binary data or non-ASCII text)
source: https://webmasters.stackexchange.com/users/12578/ilmari-karonen
based on that, you should go for the parameter Accept!
Can anybody explain the concept of content-disposition? Physically, how it can be visualized ? Specifically in case of multi-part form-data.
In a regular HTTP response, the Content-Disposition response header is
a header indicating if the content is expected to be displayed inline
in the browser, that is, as a Web page or as part of a Web page, or as
an attachment, that is downloaded and saved locally.
In a
multipart/form-data body, the HTTP Content-Disposition general header
is a header that can be used on the subpart of a multipart body to
give information about the field it applies to. The subpart is
delimited by the boundary defined in the Content-Type header. Used on
the body itself, Content-Disposition has no effect.
The Content-Disposition header is defined in the larger context of
MIME messages for e-mail, but only a subset of the possible parameters
apply to HTTP forms and POST requests. Only the value form-data, as
well as the optional directive name and filename, can be used in the
HTTP context.
MORE DETAILS
I built a servlet that allows uploading a file or alternatively uploading a list as input. So far I've handled it by setting the servlet to accept multipart/form-data so even if there is no file, I read the list as a part.
I'm now trying to call this servlet to upload a list through a JQuery AJAX method instead of through a form. If I try to upload a list normally through the method, I get:
org.apache.tomcat.util.http.fileupload.FileUploadBase$InvalidContentTypeException: the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is application/x-www-form-urlencoded; charset=UTF-8
If I set the contentType as multipart/form-data like so:
$.ajax({
url: someUrl,
type: 'POST',
contentType: 'multipart/form-data',
data: {list: inputList}
});
I get this error instead:
org.apache.tomcat.util.http.fileupload.FileUploadException: the request was rejected because no multipart boundary was found
My question is if there is some way to configure the servlet to accept both content types or alternatively is there some way to write the ajax data to upload multipart/form-data?
I know it's simple to upload multipart/form-data using the FormData API, but I need to support IE9 so this is not an option.
I suggest you to use Apache Commons FileUpload library. It provides you with a uniform interface, no matter which type of form was submitted, and makes it easy to work with uploaded files. See Section Processing the uploaded items of the User Guide, it should give you a general idea how it works.
I have two servlet: first servlet is similar to a client and creates an HttpURLConnection to call the second servlet.
I would like send a special error, formatted like a JSON object, so I call sendError method in this way:
response.sendError(code, "{json-object}")
But in the first servlet when I read error with getResponseMessage method I just get standard HTTP message and not my json object as a string.
How I can get my json string?
From the HttpServletResponse#sendError() javadoc:
The server defaults to creating the response to look like an HTML-formatted server error page containing the specified message, setting the content type to "text/html", leaving cookies and other headers unmodified. If an error-page declaration has been made for the web application corresponding to the status code passed in, it will be served back in preference to the suggested msg parameter.
So with this approach you have no other option than extracting the message from the HTML response yourself. JSoup may however be useful in this.
To achieve what you want, you need to set the error code and write the response yourself, e.g.
response.setStatus(code);
response.setContentType("application/json");
response.setCharacterEncoding("UTF-8");
response.getWriter().write(json);
Instead of code you could by the way also use one of the HttpServletResponse.SC_XXX constants for this.