About content types and ServletRequest

[sasuke]

Hello all.

I have been doing a bit of J2EE for the past few days and some things
are not very clear to me.

» What exactly happens when I set the content type? Does it help the
server or the client in understanding what to do or how to treat the
data transferred to them?

» When setting the "Content-Type" for sending binary data over the
wire (eg. byte array), what difference does it make if I choose
"application/octet-stream" or "multipart/form-data"? Can they be used
interchangeably or is there some subtle difference between them that I
should be aware of?

» In a servlet when I do:
InputStream in = request.getInputStream();
System.out.println(in.available());
I get a zero printed. Is this because the number of bytes which can be
read from the input stream without blocking is zero? If so, what could
be the logical reason behind this kind of output? Is this because
there is no guarantee when I would get a data due to some problem with
the connection? Is this behavior a part of some specification?
(Servlet / HTTP 1.1)

Please be very strict with me in answering the questions since I want
to make sure I get the entire thing correct along with the correct
type of terminology.

Thanks for your time and effort.

Regards,
/sasuke.

 

[Owen Jacobson]

Hello all.

I have been doing a bit of J2EE for the past few days and some things
are not very clear to me.

» What exactly happens when I set the content type? Does it help the
server or the client in understanding what to do or how to treat the
data transferred to them?

» When setting the "Content-Type" for sending binary data over the
wire (eg. byte array), what difference does it make if I choose
"application/octet-stream" or "multipart/form-data"? Can they be used
interchangeably or is there some subtle difference between them that I
should be aware of?

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.

» In a servlet when I do:
InputStream in = request.getInputStream();
System.out.println(in.available());
I get a zero printed. Is this because the number of bytes which can be
read from the input stream without blocking is zero? If so, what could
be the logical reason behind this kind of output? Is this because
there is no guarantee when I would get a data due to some problem with
the connection? Is this behavior a part of some specification?
(Servlet / HTTP 1.1)

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

 

[sasuke]

[snip]
Hope this was useful,
-o

Absolutely, thanks a lot Owen.

I was unsure about the difference between multipart and application/
octet-stream but I guess we use multipart when we are uploading a file
with any other form data to the server and use the application/octet-
stream when serving raw bytes to the client.

multipart -> client to server
application/octet-stream - server to client

Again thank you for lending your time and expertise.

 

[Lew]

I was unsure about the difference between multipart and application/
octet-stream but I guess we use multipart when we are uploading a file
with any other form data to the server and use the application/octet-
stream when serving raw bytes to the client.

multipart -> client to server
application/octet-stream - server to client

I don't think the octet-stream type is intrinsically tied to the direction of
the message, just that the most common (least pathological?) uses are what you
named.

It's hard to imagine a form data set going from server to client, and
certainly "multipart/form-data" was invented along with the form data set
specifically for client submissions, but after all it is simply a message
format and could be (mis)used in the other direction.