Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry@us.ibm.com
phone: 1-303-924-4080
Larry Masinter suggested that I forward this information to the HTTP-NG=
mailing list, feeling that it is relevant to discussions you have had
recently. It's a summary of a discussion that occurred on the WebDAV
mailing list about 15 months ago, about the merits of extending HTTP wi=
th
new methods vs. relying on POST with new mime types. WebDAV did start =
out
with a specification using POST, but decided to change its approach to
introduce new methods.
Issues raised on the WebDAV mailing list:
1. How do proxies / security gateways behave with POST with a new
entity-body vs. new methods? Need to do a survey.
<<RKD>> Was a survey ever done???
2. Separate methods are certain not to introduce new constraints on HTT=
P,
whereas using POST might do so.
<<RKD>> Any explanation behind this? Its certainly not obvious, since
<<RKD>> the data in a POST is opaque to the HTTP server and a new
<<RKD>> method is not!
3. Separate methods are cleaner for existing servers to deal with. Usi=
ng
POST might cause unpredictable results from existing servers. (a
controversial claim)
<<RKD>> Surely this is in jest. Servers are built to hand off the
<<RKD>> data in a POST to an application. If existing servers don't
<<RKD>> handle new methods what happens? Probably unpredictable.
4. Using separate methods stays closer to the simple OO model of the We=
b,
where operations are defined on resources.
<<RKD>> Only if the server itself is going to operate on the data.
<<RKD>> If not, then the simplest OO model seems to be to just pass the=
data
<<RKD>> thru. Now the data passed through is clean and the back-end
<<RKD>> application knows the contents of the message and the operation=
with
<<RKD>> no dependency on the server. If a new method is defined, the
<<RKD>> the interface is not clean, since the method is defined to the
<<RKD>> server, but processing of the method is really handled by a
<<RKD>> back-end application
5. It depends on your model of a web server. You can view a web server=
as
a collection of objects, with methods defined on them, a la object-orie=
nted
programming. Or you can view a web server as a collection
of agents (computational entities), of which some serve documents, whil=
e
others perform activities like "copy" or "server diff." In fact, there=
may
be many agents capable of performing an activity, and a single agent ma=
y be
capable of handling more than one type of activity. On the OO view of H=
TTP,
an HTTP message is directed to an object (the
Request-URI), which handles the method in the request message. On the a=
gent
view of HTTP, an HTTP message is directed to an agent (or a default HTT=
P
agent), which then handles either the HTTP/1.1 style message or process=
es
the command specified in the MIME type of the request message. The
advantage of the Agent view is the range of capability of the agents is=
n't
hardwired, and there may be many agents, with slightly different
characteristcs, all active simultaneously in the same server. The
advantages of the Object Oriented view stem from the fixed set of metho=
ds:
this fixed set is understood better by existing Web technology (e.g.,
caches), and can be used to implement a simple access control scheme
(method x user --> ACL).
6. Separate methods are simpler and cleaner for server vendors to
implement. (Some server implementors felt very strongly about this.)
<<RKD>> AGain, this depends on whether or not we are talking about
<<RKD>> functions to be performed in the server or functions done by
<<RKD>> back-end application outside of the server. Since I don't
<<RKD>> believe that printing will be a web server function, POST is
<<RKD>> probably cleaner.
7. It's easier to modify media types if we want to make changes later t=
han
it is to modify method definitions. (a controversial claim)
8. Access control today is based on methods, not on media types. (claim=
by
an Apache implementor)
9. Media type should not carry any semantics beyond "this is the format=
of
the content of the message body"
10. We should preserve the ability to use different media types to do t=
he
same thing.
11. The existing Web framework is built around methods. If we are talk=
ing
about extensions to HTTP/1.x, then you would expect those extensions to=
follow the framework of HTTP. If you care about the existing
implementation base and the advantages provided by HTTP's generic
interface, you will stay within the existing framework.
<<RKD>> I claim that this is only true for operations that are
<<RKD>> expected to be processed in the Web Server itself, as opposed
<<RKD>> to a back end. If we take this claim at face value, then we
<<RKD>> would define HTTP methods for **EVERY** operation that goes
<<RKD>> through a server to a back end data base, transaction system,
<<RKD>> etc. Would we expect there to be a "PAY" method when using the
<<RKD>> web to send a payment transaction to an e-business back end? Wo=
uld
<<RKD>> you expect a "QUERY DB" method when using the web to access a
<<RKD>> data base?
12. Look at PEP and what it recommends for how to extend HTTP. Decide
whether we think PEP will succeed.
=