IPP> FW: POST vs. New Methods

IPP> FW: POST vs. New Methods

Josh Cohen joshco at microsoft.com
Mon Jan 26 19:21:15 EST 1998


An interesting datapoint about new methods
vs overloading POST.


-----Original Message-----
From: Judith Slein [mailto:slein at wrc.xerox.com] 
Sent: Wednesday, January 21, 1998 1:12 PM
To: http-ng-pdg at w3.org
Subject: POST vs. New Methods




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 with
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.


2. Separate methods are certain not to introduce new constraints on HTTP,
whereas using POST might do so.


3. Separate methods are cleaner for existing servers to deal with.  Using
POST might cause unpredictable results from existing servers. (a
controversial claim)


4. Using separate methods stays closer to the simple OO model of the Web,
where operations are defined on resources.


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-oriented
programming.  Or you can view a web server as a collection
of agents (computational entities), of which some serve documents, while
others perform activities like "copy" or "server diff."  In fact, there may
be many agents capable of performing an activity, and a single agent may be
capable of handling more than one type of activity. On the OO view of HTTP,
an HTTP message is directed to an object (the
Request-URI), which handles the method in the request message. On the agent
view of HTTP, an HTTP message is directed to an agent (or a default HTTP
agent), which then handles either the HTTP/1.1 style message or processes
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 isn'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 methods:
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.)


7. It's easier to modify media types if we want to make changes later than
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 the
same thing.


11. The existing Web framework is built around methods.  If we are talking
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.


12. Look at PEP and what it recommends for how to extend HTTP.  Decide
whether we think PEP will succeed.



More information about the Ipp mailing list