Develop Reference

Setting Response Headers of HTTPServeletResponse

So, I am constructing a URL from values from a database. Now, I want to make sure that the response headers are what I specify for this URL. How do I achieve this?
For instance, if I construct a URL such as www.google.com/username=ak&password=bk, I want to make sure that the connection is keep alive for the response that you get when you hit the URL. How do I do this within JSP/Java?
The reason being, I'm trying to render a video on an iOS device from my CMS however this doesn't work and from what I have read, the response headers must be set. How do I set response headers for a URL that I might hit?
The following method is how I am setting the response however the response is not the url I make. The URL I make is something like www.uisghsfgsgsfg.com/cs/sksjdgs/appl. I am confused as to what the response means in the context of this page.
class URLConstructor extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setHeader("Accept-Ranges", "bytes");
response.setHeader("Connection", "Keep-Alive");
ByteArrayOutputStream byteStream =
new ByteArrayOutputStream(512);
response.setContentLength(byteStream.size());
response.addHeader("Connection", "Keep-Alive");
}
}

Assumption: You have access to the server which transmits the video.
The code which transmits the video to your client (IOS device) should set the response headers before sending the response(video content). If it is a Java program which serves the request for the video, you can set the appropriate header in the Servlet API (See Martin's link).
Hope that helps.

Cannot Compress Java Server Response Sent To JSP

I am having trouble in returning compressed response (GZip) from my Java Servlet, to a JSP.
Flow :
Request comes to java servlet
Process the request, and create a JSON object, with the response
Convert the JSON object to string
Compress the response string with GZip
The compressed response string is set as attribute in the request object and control passed to JSP
In the JSP, the response string (compressed) is printed on screen
Precautions :
Request object has "Accepting-Encoding" set with "gzip"
Response header has "Content-Encoding" set to "gzip"
Response content type is set to "application/json"
Response character encoding is set to "ISO-8859-1"
Result :
Firefox shows "Content Encoding Error"
Chrome shows "Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error."
Can anyone help point me out, in the right direction please?

The compressed response string is set as attribute in the request object and control passed to JSP
You shouldn't have forwarded a JSON response to a JSP. You should have printed the JSON plain to the response and have the JavaScript/Ajax code in your JSP Android app to call the URL of the servlet which returns the JSON. See also How to use Servlets and Ajax?.
As to the GZIP compression, you shouldn't do it yourself. Let the server do itself.
Fix your code to remove all manual attempts to compress the response, it should end up to basically look like this:
#Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String json = createItSomehow();
response.setContentType("application/json");
response.setCharacterEncoding("UTF-8");
response.getWriter().write(json);
}
That's all, if you let your Android app call the URL of the servlet, it'll retrieve the JSON string.
Finally edit the server configuration to turn on automatic GZIP compression. In case of for example Tomcat, that would be a matter of adding compression="on" to the <Connector> element in Tomcat's /conf/server.xml file:
<Connector ... compression="on">
As per the documentation, the compressable mime types defaults to text/html,text/xml,text/plain. You can configure this to add application/json.
<Connector ... compression="on" compressableMimeType="text/html,text/xml,text/plain,application/json">
Unrelated to the concrete problem, the response character encoding must be set to UTF-8 which is as per the JSON specification.

JSPs are for rendering textual data to the client. GZIP is binary data, even if it is compressed text underneath.
I suggest using a GZIP servlet filter to compress your data on the fly, instead of doing it programmatically in your business logic.
See this prior question for how to get hold of one off-the shelf: Which compression (is GZIP the most popular) servlet filter would you suggest?
Failing that, then write your own servlet filter that does the same thing.

How to drop body of a request after checking headers in Servlet

I want to check the header of the request whether it contains a certain header or not before continuing with the body. For example, I want to check whether a multipart/form-data contains "Authorization" in the header or not. If it is not then there is no need to continue with uploading the multipart body which are generally quite large for file uploading.
Does servlet allow you to do this? I have tried to search on google randomly but there is no luck. Here is the code i try in my servlet but it still continues with recieving the body before this doPost method is called. It seems that the stream is fully received before the servlet is invoked.
#Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
response.setContentType("text/plain");
if (request.getHeader("Authorization") == null) {
response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
out.println("Status: " + HttpServletResponse.SC_UNAUTHORIZED + " - UNAUTHORIZED");
return;
}
// ... the rests
}

That's the limitation of HTTP. You can't send a response when the request hasn't been read fully to end.

RFC 2616 says:
An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body.
So I disagree, this is not a HTTP limitation but a servlet one.

How to make a servlet interact with the API of a website and also store the XML response?

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String text = "some text";
response.setContentType("text/plain"); // Set content type of the response so that jQuery knows what it can expect.
response.setCharacterEncoding("UTF-8"); // You want world domination, huh?
response.getWriter().write(text); // Write response body.
}
If I use this servlet , where request variable will have the url of the API of the website . Then how do I capture the response ? I would want to know what is the code to do that , and is this the right way to go about it when trying to build a JSP page that deals with interacting with an API of a website and showing data ?

You're confusing things. The HttpServletRequest is the HTTP request which the client (the webbrowser) has made to reach the servlet. The HttpServletResponse is the response which you should use to send back the result to the client (the webbrowser).
If you want to fire a HTTP request programmatically, you should use java.net.URLConnection.
URLConnection connection = new URL("http://example.com").openConnection();
InputStream input = connection.getInputStream(); // This contains the response. You need to convert this to String or some bean and then display in JSP.
See also:
How to use java.net.URLConnection to fire and handle HTTP requests

How to send byte[] as pdf to browser in java web application?

In action method (JSF) i have something like below:
public String getFile() {
byte[] pdfData = ...
// how to return byte[] as file to web browser user ?
}
How to send byte[] as pdf to browser ?

In the action method you can obtain the HTTP servlet response from under the JSF hoods by ExternalContext#getResponse(). Then you need to set at least the HTTP Content-Type header to application/pdf and the HTTP Content-Disposition header to attachment (when you want to pop a Save As dialogue) or to inline (when you want to let the webbrowser handle the display itself). Finally, you need to ensure that you call FacesContext#responseComplete() afterwards to avoid IllegalStateExceptions flying around.
Kickoff example:
public void download() throws IOException {
// Prepare.
byte[] pdfData = getItSomehow();
FacesContext facesContext = FacesContext.getCurrentInstance();
ExternalContext externalContext = facesContext.getExternalContext();
HttpServletResponse response = (HttpServletResponse) externalContext.getResponse();
// Initialize response.
response.reset(); // Some JSF component library or some Filter might have set some headers in the buffer beforehand. We want to get rid of them, else it may collide.
response.setContentType("application/pdf"); // Check http://www.iana.org/assignments/media-types for all types. Use if necessary ServletContext#getMimeType() for auto-detection based on filename.
response.setHeader("Content-disposition", "attachment; filename=\"name.pdf\""); // The Save As popup magic is done here. You can give it any filename you want, this only won't work in MSIE, it will use current request URL as filename instead.
// Write file to response.
OutputStream output = response.getOutputStream();
output.write(pdfData);
output.close();
// Inform JSF to not take the response in hands.
facesContext.responseComplete(); // Important! Else JSF will attempt to render the response which obviously will fail since it's already written with a file and closed.
}
That said, if you have the possibility to get the PDF content as an InputStream rather than a byte[], I would recommend to use that instead to save the webapp from memory hogs. You then just write it in the well-known InputStream-OutputStream loop the usual Java IO way.

You just have to set the mime type to application/x-pdf into your response. You can use the setContentType(String contentType) method to do this in the servlet case.
In JSF/JSP you could use this, before writing your response:
<%# page contentType="application/x-pdf" %>
and response.write(yourPDFDataAsBytes()); to write your data.
But I really advise you to use servlets in this case. JSF is used to render HTML views, not PDF or binary files.
With servlets you can use this :
public MyPdfServlet extends HttpServlet {
protected doGet(HttpServletRequest req, HttpServletResponse resp){
OutputStream os = resp.getOutputStream();
resp.setContentType("Application/x-pdf");
os.write(yourMethodToGetPdfAsByteArray());
}
}
Resources :
mimeapplication.net - pdf
Javadoc - ServletResponse
Javadoc - HttpServlet

When sending raw data to the browser using JSF, you need to extract the HttpServletResponse from the FacesContext.
Using the HttpServletResponse, you can send raw data to the browser using the standard IO API.
Here is a code sample:
public String getFile() {
byte[] pdfData = ...
FacesContext context = FacesContext.getCurrentInstance();
HttpServletResponse response = (HttpServletResponse) context.getExternalContext().getResponse();
OutputStream out = response.getOutputStream();
// Send data to out (ie, out.write(pdfData)).
}
Also, here are some other things you might want to consider:
Set the content type in the HttpServletResponse to inform the browser you're sending PDF data:
response.setContentType("application/pdf");
Inform the FacesContext that you sent data directly to the user, using the context.responseComplete() method. This prevents JSF from performing additional processing that is unnecessary.