First, read the HTTP specification.  It's relatively short, and
explains the purpose of Content-Type.  See section 7.2.1.

 <http://www.faqs.org/rfcs/rfc2616.html>

Got that?  Good.

There are actually two content types involved in an HTTP round trip:
the client's request may (for POSTed data) have a Content-Type header
indicating how to parse the form data, which is where multipart/form-
data comes in: that content type is required for forms that submit
files, and for any other "multiple part" HTTP request.  The second
content type is the one sent with the server's response, for responses
that have a body.  200 Okay has a response body (the page), and
therefore a Content-Type header.

One of the other things Content-Type usually contains is an indication
of what encoding is in use in the corresponding body.  If you are
sending UTF-8 text back, the content type has to be one of the text/*
content types with charset=UTF-8 for the browser to correctly handle
characters above codepoint 127.  The "application/octet-stream" is a
generic content type that says "this body is an opaque sequence of
octets" - that it's not for the browser to interpret or present.

When you call response.setContentType (...) in a servlet, or set the
contentType of a JSP via page directives, you're controlling the
content type header sent back to the client.  The type you send must
match the content you intend to send; while some browsers will try to
"guess" the correct type if you send the wrong one, it's unreliable
and will bite you.  There's a fairly complete list of type names
maintained by IANA (who are responsible for assigning them) at
 <http://www.iana.org/assignments/media-types/>

There are also vendor-specific MIME types, which are denoted with 'x-'
or 'vnd.' -- for example, audio/x-mpeg was, for a while, the de facto
content type for MP3s until IANA accepted the 'audio/mpeg' content
type.

If you want to see how this plays out in practice, get a tool like
wireshark that allows you to watch network traffic and examine it and
see what your browser sends to and gets back from the server when you
visit a web page.  Pick something simple; complex pages (like google
groups :) generate a huge amount of traffic to pick through.

The behaviour of the 'available()' method of InputStreams is
completely specified by InputStream's documentation:

 <http://java.sun.com/javase/6/docs/api/java/io/
InputStream.html#available()>

With the input stream representing POSTed data from a client, very
often there is no guarantee that any data can be read "without
blocking"; in general, available() is a poor way to check for data
readiness and is best used for diagnostics rather than logic.  Just
read the stream.

Hope this was useful,
-o