Subject: Question of many METHODs

From: Kojiro Goto <[email-masked]>
Date: Wed, 05 Apr 2000 18:24:04 +0900

Hello,

I have a question about HTTP Protocol.
I wonder if all of METHODs have been actually used (or
implemented?) because there are so MANY METHODs

[1] TRACE
  This function is like UNIX TRCEROUTE COMMAND?
  This is only for Debug?
  Is it useful?

[2] PUT
  Is this the same as FTP PUT?

[3] DELETE
  This is to delete files on a server?
  If so, isn't it a security issue?

[4] OPTIONS
  What the function is for?

A client (User Agent) must support all of these METHODs?
I do not like to implement METHODs which I rarely use.
As XTHML1.1-Basic will include a thin spec for a thin client,
there must be a thin HTTP spec which supports only necessary
functions.
I am thinking that above [1],[3] and [4] are not necessary.

Is there anybody who knows such a thin spec?
Any information or opinion is welcomed.

Sincerely,

-- Kojiro Goto
-- [email-masked]

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Wed, 5 Apr 2000 14:56:40 +0200

Only some are commonly used.

=== COMMONLY USED for Browsing ===
GET - Retreive documents, used most by your web browser
POST - Posting forms of HTML pages (commonly used)

=== HTTP/1.1 WEB EDITING ===
HEAD - Commonly used for testing hyperlinks (same as GET, but without
data/content)
PUT - Sending a file to a web server
DELETE - Remove files

=== Admin ===
OPTIONS - Setting settings on a web server or proxy server??? don't know
exactly....
TRACE - Tracing the path of a request through proxy servers and to a web
server

If you are building a simple HTTP/1.1 interface you should implement
	GET and POST

HEAD can be done simply using the same code as GET, but you don't get the
data/content)

PUT/DELETE/e.d. should be implemented if you plan web publishing or
authoring

Since I was building a proxy server, these functions are mostly used (GET &
POST).
If you build a proxy server, it's recommended to implement the CONNECT
command for
tunneling, but this not in your case (i think).

HTTP/1.1 also supports authentication and much more methods to secure data
on a web server. The PUT, DELETE, e.d. functions are not a security issue if
they require you to authenticate with digest or NTLM authentication (or some
alike). Also it's possible to use HTTPS for web publishing, what even
protects the data being transmitted, useful for sensative documenents.

So don't worry about security, just ensure you are making the library
HTTP/1.1-compliant and are a bit compatible with HTTP/1.0, what should not
be an issue if you follow the standards.

	Joris Dobbelsteen
	[email-masked]

-----Original Message-----
From: Kojiro Goto [mailto:[email-masked]]
Sent: woensdag 5 april 2000 11:24
To: [email-masked]
Subject: Question of many METHODs

Hello,

[1] TRACE

[2] PUT

[3] DELETE

[4] OPTIONS

Sincerely,

-- Kojiro Goto
-- [email-masked]

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 5 Apr 2000 09:04:27 -0400

> From: Kojiro Goto <[email-masked]>

>   This function is like UNIX TRCEROUTE COMMAND?

I've found it very usefull when trying to determine what various
proxies do to requests; it let's you see how the request arrived at
the server (as opposed to what you sent).

>   Is this the same as FTP PUT?

It serves the same purpose.

>   This is to delete files on a server?

Yes.

>   If so, isn't it a security issue?

No more so than any other security issue - the server can enforce
whatever security it wants to for any method.

>   What the function is for?

It was meant to be a means of probing what features the server
supported, but never really got finished in that no standard way of
expressing much usefull information was specified.

It is usefull as a no-op request for determining whether or not the
server supports 1.1, or for carrying a request to upgrade (see
"Upgrading to TLS Within HTTP/1.1" -
draft-ietf-tls-http-upgrade-04.txt; approved as Proposed Standard
but not yet out of the RFC Editors queue).

> A client (User Agent) must support all of these METHODs?

Since HTTP is always initiated by the client, it cannot be forced to
send any method, so in some sense it needn't support any methods it
doesn't want to.

--
Scott Lawrence      Director of R & D        <[email-masked]>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/