📄 ch26.htm
字号:
<HTML>
<HEAD>
<TITLE>Chapter 26 -- NSAPI</TITLE>
<META>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EE" VLINK="#551A8B" ALINK="#CE2910">
<H1><FONT COLOR=#FF0000>Chapter 26</FONT></H1>
<H1><B><FONT SIZE=5 COLOR=#FF0000>NSAPI</FONT></B>
</H1>
<P>
<HR WIDTH="100%"></P>
<P>
<H3 ALIGN=CENTER><FONT COLOR="#000000"><FONT SIZE=+2>CONTENTS<A NAME="CONTENTS"></A>
</FONT></FONT></H3>
<UL>
<LI><A HREF="#WhyNSAPI" >Why NSAPI?</A>
<LI><A HREF="#NSAPIversusCGI" >NSAPI versus CGI</A>
<UL>
<LI><A HREF="#Performance" >Performance</A>
<LI><A HREF="#ProcessSpace" >Process Space</A>
<LI><A HREF="#DataandFunctionAccess" >Data and Function Access</A>
</UL>
<LI><A HREF="#NSAPIandtheServersProcesses" >NSAPI and the Server's Processes</A>
<UL>
<LI><A HREF="#HTTPRequestResponseProcess" >HTTP Request/Response Process</A>
<LI><A HREF="#ServerApplicationFunctions" >Server Application Functions</A>
<LI><A HREF="#ControllingFunctionUse" >Controlling Function Use</A>
</UL>
<LI><A HREF="#FunctionsandFeatures" >Functions and Features</A>
<UL>
<LI><A HREF="#ServerApplicationFunctionPrototype" >Server Application Function Prototype</A>
<LI><A HREF="#ParameterBlocks" >Parameter Blocks</A>
<LI><A HREF="#Sessions" >Sessions</A>
<LI><A HREF="#RequestStructure" >Request Structure</A>
<LI><A HREF="#FunctionsVariablesandTheirResponse" >Functions, Variables, and Their Responses</A>
</UL>
<LI><A HREF="#ImplementationConsiderations" >Implementation Considerations</A>
<UL>
<LI><A HREF="#CrossPlatformCapabilities" >Cross-Platform Capabilities</A>
<LI><A HREF="#InformationalResources" >Informational Resources</A>
<LI><A HREF="#ProgrammingKnowledge" >Programming Knowledge</A>
<LI><A HREF="#Debugging" >Debugging</A>
</UL>
<LI><A HREF="#TheFutureoftheNSAPI" >The Future of the NSAPI</A>
<LI><A HREF="#Summary" >Summary</A>
</UL>
<HR>
<P>
What do you do if your server can't do what you want it to? Buy
another server? Not do what you were planning on? Even CGI programs
can't really change the way a server works; they can only add
on specific functions that need to be called in a specific way.
Another way does exist, however.
<P>
The Netscape Server API, or NSAPI, enables you to add functions
to your server, like CGI, but it also enables you to change the
way the server works at the very core of its functionality. Don't
like the way errors are handled? Change the error handling. Not
enough information being logged? Change the logging system. Want
to add your own custom authorization mechanism? Go right ahead.
The power exists for you to change almost any function that the
server performs, as well as add whatever pieces you want.
<P>
In this chapter, you explore the world of the NSAPI and see what
it means to Netscape as well as to you, the developer/user. The
primary focus areas are as follows:
<UL>
<LI><FONT COLOR=#000000>Why NSAPI?</FONT>
<LI><FONT COLOR=#000000>NSAPI versus CGI</FONT>
<LI><FONT COLOR=#000000>NSAPI and the server's processes</FONT>
<LI><FONT COLOR=#000000>Functions and features</FONT>
<LI><FONT COLOR=#000000>Implementation complications</FONT>
<LI><FONT COLOR=#000000>Future directions</FONT>
</UL>
<P>
Let me give you advance warning: creating and using NSAPI functions
require a thorough knowledge of C programming. Some of the information
contained in this chapter may be of more use if you have a programming
background, as I cover data structures, function calls, and general
programming issues. The real focus of this chapter, though, is
to provide you with a detailed overview of the NSAPI itself so
that you have a starting point if you want to pursue it further.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Caution</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Before you spend too much time learning about the NSAPI standard, make sure that your server supports it. It is native only to Netscape servers, and there are certain other server packages and versions that have added, or are adding, NSAPI support. You
wouldn't want to create a great function only to find out it can't be of any use to you.</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<H2><A NAME="WhyNSAPI"><FONT SIZE=5 COLOR=#FF0000>Why NSAPI?</FONT></A>
</H2>
<P>
When building their servers, Netscape couldn't possibly anticipate
exactly how you would want to work. They could and have built
in a great deal of flexibility to enable you to perform most of
the tasks you want, but you will always have a set of functions
or a way of doing business that is unique to your situation. Support
for the open CGI standard allows easy access to functionality
to extend the server's reach, but in a world where things need
to be faster, more flexible, and more seamlessly integrated, easy
access is often not enough.
<P>
Netscape has a vision, and that vision is the Internet Application
Framework. Sounds all-encompassing, doesn't it? Well, it is. The
overall focus of Netscape's efforts is to create a set of open
standards and protocols that any developer can use to get the
functionality that he or she needs for Internet and intranet applications.
As part of Netscape's <I>Open Network Environment (ONE)</I> philosophy,
the Internet Application Framework and NSAPI, specifically, play
pivotal roles in defining the next generation of applications.
Figure 26.1 shows Netscape's representation of this Internet Application
Framework. The figure also shows that in Netscape's vision NSAPI
and CGI (along with other technologies) reside in the category
of Server APIs (Application Programming Interfaces).
<P>
<A HREF="f26-1.gif" ><B>Figure 26.1 : </B><I>Netscape's representation of their Internes Application Framework.</I></A>
<P>
Server APIs are the methods that you can use to extend your server's
functionality. An API is nothing more than a way to get at special
bits of data and exert an amount of control over the server itself,
through a variety of methods.
<P>
Unlike CGI, whose open standard is supported by almost every server
in existence, no open standard currently exists for Web servers.
This lack of standard presents a problem, and it goes rather deep-each
server is different, and its insides operate in different ways.
Without forcing every server developer to adopt the same methodology
in how he or she processes data internally, no common ground can
be had for every server to take advantage of. Although this situation
might present a problem for some companies, it's just another
opportunity for Netscape.
<P>
With its broad base of users, Netscape can influence Internet
trends, including HTML, security issues, and servers themselves.
Most of this influence is through just adopting what Netscape
feels is a good method of doing something and going with it. In
a few cases, arbitrary additions meet with unanimous approval
(frames, for instance), but Netscape has enough momentum to avoid
being bogged down by a need for everyone to endorse what they've
designed. Much like Microsoft often says, "This is the standard
that software must conform to." Because they control a great
percentage of the operating systems market, Netscape has a similar
kind of power in the Internet environment, and it is due to their
setting the trends, not following them.
<P>
The NSAPI is Netscape's next venture into trend-setting standards,
though it will be a much more difficult task. The first reason
is, as I mentioned before, that it involves having the server
work in a specific way. The second is that it requires a reasonably
high level of expertise to create a useful and robust API function.
The final reason is the one that may be the biggest obstacle:
Netscape is not alone in their proposal for a server API standard.
The challengers are numerous, but the biggest competition comes
from one source-the combination of Microsoft and Process Software
to create the Internet Server API (ISAPI).
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Note</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Later in this chapter I cover in more detail the future of the NSAPI amidst these challenges. You can also review the ISAPI in <A HREF="ch25.htm" >Chapter 25</A>, "ISAPI."
</BLOCKQUOTE>
</TD></TR>
</TABLE></CENTER>
<P>
<P>
Why, then, with all these challenges, would anyone pursue the
creation of NSAPI functions? To begin to understand that question,
you must start by comparing NSAPI functions to the CGI standard
to understand where they're similar and where they part company.
<P>
As you can see from the diagram shown in Figure 26.1, many other
components fit naturally into the creation of Internet applications,
but the role of NSAPI itself is the focus of attention here. Both
CGI and NSAPI provide additional server-side functionality; that
is, they isolate data processing from the client for convenience,
security, and/or speed. The key difference is that a CGI program
is built to take advantage of data gathered by the server and
operate outside the boundaries of the HTTP server's environment,
whereas NSAPI functions are built directly into the server itself,
extending its core functionality to meet individual or corporate
needs.
<H2><A NAME="NSAPIversusCGI"><FONT SIZE=5 COLOR=#FF0000>NSAPI
versus CGI</FONT></A></H2>
<P>
Of all the server software produced anywhere in the world, only
a small fraction provides no support for the CGI standard or some
closely related independent extension. The reason is that CGI
makes sense. You can't expect the server manufacturer to know
everything you want to do with the software, and often you wouldn't
want the manufacturer to cramp your style even if it could predict
some form of what you wanted.
<P>
As you've seen throughout this book, using CGI can be an easy
and powerful way to extend the server's functionality without
too much fuss.
<H3><A NAME="Performance">Performance</A></H3>
<P>
API functions are faster than CGI functions. How much faster?
They are anywhere from two to five times as fast, depending on
what you're doing. Knowing how important it is to get work done
as fast as possible on the Internet, this speed is a good thing.
<H3><A NAME="ProcessSpace">Process Space</A></H3>
<P>
API functions share process space with the server itself. As a
result, these functions are faster. Every time a server executes
a CGI program, on the other hand, a new process is started up
for that program, and it doesn't like to share with anybody. That's
one process per CGI execution. Imagine how much server effort
that process causes if your server gets tens of thousands of CGI
hits a day. And people wonder why server's need so much memory.
<P>
If you look through a CGI script, you'll see that it's just not
designed to be nice to other applications that may need extra
memory or processor time. Each script wants to do its task as
fast as possible and get out of there. Although this capability
may not be bad for most functions, think of database functions.
Say you have a database with 400,000 records in it, and you're
doing a search off a subset within your CGI script. Every time
you want to do some Inter-Process Communications to whatever manages
your data source, you're in for a long haul. API functions, on
the other hand, share resources of any kind and can coexist peacefully
whether they're dealing with an external or an internal resource.
<H3><A NAME="DataandFunctionAccess">Data and Function Access</A>
</H3>
<P>
The largest advantage that an API function has over a CGI program
is the amount of data and number of functions that the server
has available but can't be accessed from "outside the loop"
of its own process space. CGI is designed to receive data and
send data in a limited fashion through intermediaries (environment
variables and STDOUT, normally). API functions, however, are part
of the server itself and can cause the server to take some action
or intercept some action that the server might normally do.
<P>
Suppose that you have a page that requires authorization, and
someone within your company who isn't authorized tries to access
it. You could intercept the error message that would normally
go back, identify who the user is, and then present more appropriate
feedback, such as "Sorry, Bob, you don't currently have access
to the Technical Specifications for that product. The contact
person for your department's questions is Janet, who can be reached
at extension 58. Your regional contact is Joe, who can be reached
at 555-0101 for any questions when Janet isn't available."
As you can see, this message is a lot more helpful than the <TT><FONT FACE="Courier">Access
Denied</FONT></TT> message. By building this functionality as
an additional server function, all your company's servers can
easily make use of similar functionality, and it will be transparent
to the users and even to some of the administrators.
<P>
The preceding example is just a sampling of what you can do, and
without having much impact on your server's performance at all.
You can create customized logging entries, security functions,
reporting, automatic document conversion, and even "cookie"-like
information for maintaining user states while they're accessing
your pages. The functionality you add is all up to you, your needs,
and your imagination.
<P>
To help you better understand the ways in which the NSAPI enables
you to get better acquainted with your server, I delve into some
of the functions and structures that make the NSAPI what it is
in the following sections.
<H2><A NAME="NSAPIandtheServersProcesses"><FONT SIZE=5 COLOR=#FF0000>NSAPI
and the Server's Processes</FONT></A></H2>
<P>
NSAPI works by acting in place of, or in addition to, specific
server functions. By crawling around inside your server's configuration
files and changing what things are being done, you can rebuild
the server in any way you want. Not only are you customizing it
to meet your needs, but you're also learning how it worked in
the first place.
<H3><A NAME="HTTPRequestResponseProcess">HTTP Request/Response
Process</A></H3>
<P>
The server functions that you're adjusting to your own purposes
take place in a specific order, starting as soon as the client
sends a message that says, "I'd like this file." This
process is called an <I>HTTP Request/Response process</I>; it's
the series of tasks that occurs once the client has sent data,
and the duty rests with the server to complete the exchange of
information.
<P>
To come to grips with how Netscape servers treat this whole process,
look at Netscape's own definition of what the HTTP Request/Response
process looks like, as shown in Table 26.1.
<P>
<CENTER><B>Table 26.1. Netscape's HTTP Request/Response process.</B></CENTER>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><CENTER><I>Process</I></CENTER></TD><TD WIDTH=402><CENTER><I>Purpose</I></CENTER>
</TD></TR>
<TR><TD WIDTH=188>Authorization Translation</TD><TD WIDTH=402>Any client authorization data converted into user and group for server
</TD></TR>
<TR><TD WIDTH=188>Name Translation</TD><TD WIDTH=402>URL translated or modified, if necessary
</TD></TR>
<TR><TD WIDTH=188>Path Checks</TD><TD WIDTH=402>Local access tests to ensure document can be safely retrieved
</TD></TR>
<TR><TD WIDTH=188>Object Type Check</TD><TD WIDTH=402>Evaluate the MIME type for the given object (document)
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -