[Zope3-dev] Other (than GET and POST) HTTP Methods

[Casey Duncan]

On Wednesday 08 January 2003 06:26 am, Jim Fulton wrote:
> Stephan Richter wrote:
> > On Tuesday 07 January 2003 14:41, Jim Fulton wrote:
[snip]> >=20
> >=20
> >>- Treat each method (or some grouping of methods) as a view type.
> >>   For example, we've treated the pair of methods, GET and POST as
> >>   the "Browser" view type.  The problem is that I'm not sure there
> >>   are good groupings. For example, WebDAV uses GET and PUT, as well =
as
> >>   several WebDAV-specific methods.
> >=20
> >=20
> > I think I like this one the best. Does a duplication of the methods r=
eally=20
> > matter or is there a conflict if we do?
>=20
> Yes. It should be possible to provide PUT without providing all of WebD=
AV.

I would argue that PUT is not really DAV specific. DAV uses it, but it is=
 part=20
of the underlying HTTP spec.
>=20
> Then again, as a practical matter, we will end up providing WebDAV and
> PUT is just a subset. In the short term, however, I want PUT and I don'=
t
> want to have to implement all of WebDAV just to get PUT.
>=20
>  > Should WebDAV run on the same port as
> > BrowserHTTP?
>=20
> For content editing, probably. You definately want to be able to
> support PUT on the same port.

IMHO: DAV should not run on the same port as normal HTTP, from experience=
 in=20
Zope 2, there is no 100% reliable way to distinguish DAV requests from no=
rmal=20
ones and in some cases we want different semantics, like for GET requests=
 on=20
templates (rendered vs. unrendered).

OTOH running it on the same port does make external editor simpler ;^)

As I said, PUT is not DAV, so running DAV on another port doesn't preclud=
e=20
have PUT on the regular HTTP port.

Also, are we sure a DAV PUT is exactly the same as a normal HTTP PUT? Or =
would=20
you ever want different semantics for them? For instance, would we want a=
 DAV=20
lock to affect both ports (part of me says yes), and if so how do we deal=
=20
with locking?
=20
>  > If not, we do the same as we did for XML-RPC and just create a
> > WebDAVPublisher that is derived from HTTPPublisher.
>=20
> But we do want PUT on the same port.

I think DAV might use the PUT from the main port and simply extend it. Pe=
rhaps=20
there can be two (or more) interfaces. Like IHttpPuttable and=20
IWebDavResource, the latter derived from the former.
=20
> > Oh, at this point I remember how Shane and I planned all this out! I =
was=20
> > right, we should have another type of HTTPPublisher, called=20
WebDAVPublisher,=20
> > which does all the right things. Then you can create either a server =
that=20
> > starts the WebDAV service on a seperate port
>=20
> This isn't what you want for content editing. It's not what you want
> when using Amaya or Composer to edit content pages.
>=20
>  > or you write a RequestFactory
> > that knows how to correctly decide between BrowserHTTP or WebDAVHTTP.
>=20
> You can't distinguish Browser GETs from WebDAV, Amaya, or Composer GETs=
=2E
> You can't distinguish WebDAV PUTs from Amaya, or Composer PUTs.

I'm not sure I understand. lets say for the sake or argument that we supp=
ort=20
PUT on the main HTTP port and run a separate DAV port also supporting PUT=
=20
plus the rest of the DAV verbs.=20

If you use a DAV client then you configure it to talk to the DAV port. If=
 its=20
just a straight HTTP client, only using PUT, GET, POST, etc then it uses =
the=20
standard port.

You know which is WebDAV based on the port the thing connects to. You don=
't do=20
request body sniffing like we do now.
=20
-Casey