Whoa. What’s the deal with content type?

You might be wondering about this line:

response.setContentType("application/jar");

Or at least you should be. You have to tell the browser what you’re sending back, so the browser can do the right thing: launch a “helper” app like a PDF viewer or video player, render the HTML, save the bytes of the response as a downloaded file, etc. And since you’re wondering, yes when we say content type we mean the same thing as MIME type. Content type is an HTTP header that must be included in the HTTP response.

image with no caption

Common MIME types:

text/html

application/pdf

video/quicktime

application/java

image/jpeg

application/jar

application/octet-stream

application/x-zip

Relax

You don’t need to memorize a bunch of content types.

You should know what setContentType() does, and how you use it, but you don’t have to know even the most common content types except text/html What you need to know about setContentType() is mostly common sense... for example, it won’t do you any good to change the content type AFTER you write to the response output stream. Duh. But that does mean that you can’t set a content type, write some stuff, and then change the content type and write something different. But think about it—how would the browser deal with that? It can handle only one type of THING at a time from the response.

To make sure everything works correctly, your best practice (and in some cases a requirement) is to always call setContentType() first, BEFORE you call the method that gives you your output stream (getWriter() or getOutputStream()). That’ll guarantee you won’t run into conflicts between the content type and the output stream.

There are no Dumb Questions

Q:

Q: Why do you have to set the content type? Can’t servers figure it out from the extension of the file?

A:

A: Most servers can, for static content. In Apache, for example, you can set up MIME types by mapping a specific file extension (.txt, .jar, etc.) to a specific content type, and Apache will use that to set the content type in the HTTP header. But we’re talking about what happens inside a servlet where there IS no file! You’re the one who is sending back the response; the Container has no idea what you’re sending.

Q:

Q: But what about that last example where you read a specific JAR file? Can’t the Container see that you’re reading a JAR?

A:

A: No. All we did from the servlet was read the bytes of a file (that just happened to be a JAR file), and turn around and write those bytes to the output stream. The Container has no idea what we were up to when we read those bytes. For all it knows we’re reading from one type of thing and writing something completely different in the response.

Q:

Q: How can I find out what the common content types are?

A:

A: Do a Google search. Seriously. New MIME types are being added all the time, but you can easily find lists on the Web. You can also look in your browser preferences for a list of those that have been configured for your browser, and you can check your Web server configuration files as well. Again, you don’t have to worry about this for the exam, and it’s not likely to cause you much stress in the real world either.

Q:

Q: Wait a second... why would you use a servlet to send back that JAR file when you can just have the web server send it back as a resource? In other words, why wouldn’t you have the user click a link that goes to the JAR instead of to a servlet? Can’t the server be configured to send back the JAR directly without even GOING through a servlet?

A:

A: Yes. Good question. You COULD configure the web server so that the user clicks an HTML link that goes to, say, the JAR file sitting on the server (just like any other static resource including JPEGs and text files), and the server just sends it back in the response.

But... we’re assuming that you might have other things that you want to do in that servlet BEFORE sending back the stream. You might, for example, need logic in the servlet that determines which JAR file to send. Or you might be sending back bytes that you’re creating right there on-the-fly. Imagine a system where you take input parameters from the user, and then use them to dynamically generate a sound that you send back. Sound that didn’t previously exist. In other words, sound that’s not sitting on the server as a file somewhere. You just made it up, and now you’re sending it back in the response.

So you’re right, perhaps our example of just sending back a JAR sitting on the server is a little contrived, but come on... use your imagination here and embellish it with all sorts of things you might add to make it worth being a servlet. Maybe it’s something as simple as putting code in your servlet that—along with sending back the JAR—writes some info to a database about this particular user. Or maybe you have to check to see if he’s even allowed to download this JAR, based on something you first read from the database.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset