W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: PEP and new methods

From: Dan Connolly <connolly@w3.org>
Date: Wed, 19 Feb 1997 15:41:13 -0600
Message-Id: <330B7379.7D9A6050@w3.org>
To: "Gregory J. Woodhouse" <gjw@wnetc.com>
Cc: HTTP WG Mailing List <http-wg@cuckoo.hpl.hp.com>
Gregory J. Woodhouse wrote:
> 
> I've been looking at the latest PEP draft and it's not at all clear to me
> how to go about negotiating new methods. I'm working on a project that I'd
> like to build on top of HTTP/1.1, but it will definitely require
> LINK/UNLINK and may require additional methods.

The HTTP 1.1 spec says:

=====================
9 Method Definitions

The set of common methods for HTTP/1.1 is defined below. Although this
set
can be expanded, additional methods cannot be assumed to share the same
semantics for separately extended clients and servers.
======================

In this case, PEP is just a way to establish shared semantics between
"separately extended clients and servers."

I'm not quite certain of a few relavent details:

* Is a request using a method of LINK allowed by the current definition
of HTTP 1.1? I believe so, in the same way that extension header
fields are legal.

* What should/may/must proxies do with LINK and other unknown methods?
What do they actually do in practice?
I would expect them to forward the request, but assume that the
method is not 'safe' (in the sense of 9.1.1 Safe Methods)

* Is your use of LINK adequately describe by the existing specification,
or does it need further semantic agreement between the parties?


Since you mention the possibility of other methods besides LINK, I
would suggest that you define a PEP extension; that is:

	(1) choose a URL to identify the extension
	(2) make the specification of your extension available at
		that address
	(3) use PEP to advertise support of this extension
	(4) use the URL extension identifier in extended requests

e.g.:

some response...

	HTTP/1.1 200 Okie Dokie
	Protocol-Info: {http://some.where/link/stuff {for /linkdb/ *}
				{str opt} }


then later, a request from a client that saw that response:

	LINK /linkdb/foo HTTP/1.1
	Protocol: {http://some.where/link/stuff }
	Host: client.host

	...

That way, you can tell which client support the extension.
(you didn't say whether that was necessary... if it is,
then PEP is particularly useful)

As Rohit says, this is not so much a case of negotiation as just
identifying extensions.

Dan
Received on Wednesday, 19 February 1997 13:46:38 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:29 EDT