Java Network Programming (3rd ed) [Electronic resources] نسخه متنی

Chapter 16. Protocol Handlers

When designing an architecture that
would allow them to build a self-extensible browser, the engineers at
Sun divided the problem into two parts: handling protocols and
handling content. Handling a protocol involves the
interaction between a client and a server: generating requests in the
correct format, interpreting the headers that come back with the
data, acknowledging that the data has been received, etc. Handling
the content involves converting the raw data into a format Java
understandsfor example, an InputStream or
an AudioClip. These two problems, handling
protocols and handling content, are distinct. The software that
displays a GIF image doesn't care whether the image
was retrieved via FTP, HTTP, gopher, or some new protocol. Likewise,
the protocol handler, which manages the connection and interacts with
the server, doesn't care if it's
receiving an HTML file or an MPEG movie file; at most, it will
extract a content type from the headers to pass along to the content
handler.

Java divides the task of handling protocols into a number of pieces.
As a result, there is no single class called
ProtocolHandler. Instead, four different classes
in the java.net package work together to implement
the protocol handler mechanism. Those classes are
URL,
URLStreamHandler,
URLConnection, and
URLStreamHandlerFactory. URL is
the only concrete class in this group;
URLStreamHandler and
URLConnection are abstract classes and
URLStreamHandlerFactory is an interface.
Therefore, if you are going to implement a new protocol handler, you
have to write concrete subclasses for the
URLStreamHandler and the
URLConnection. To use these classes, you may also
have to write a class that implements the
URLStreamHandlerFactory interface.