Re: mailserver URL

Gary Adams - Sun Microsystems Labs BOS (Gary.Adams@east.sun.com)
Tue, 31 Jan 1995 08:06:33 +0500


Date: Tue, 31 Jan 1995 08:06:33 +0500
From: Gary.Adams@east.sun.com (Gary Adams - Sun Microsystems Labs BOS)
Message-Id: <9501311306.AA08015@zeppo.East.Sun.COM>
To: uri@bunyip.com, fielding@avron.ICS.UCI.EDU
Subject: Re: mailserver URL 


> Subject: Re: mailserver URL 
> Date: Mon, 30 Jan 1995 20:13:36 -0800
> From: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>

> >>Arbitrary header fields introduce an unacceptable security hazard.
> 
> 2) If you strongly believe that the mailserver URL should NOT have the
>    ability to include arbitrary header field values, please send a message
>    stating such opinion to the list at <uri@bunyip.com> or to the author
>    Paul Hoffman <ietf-lists@proper.com>.
> 

I have not heard a compeling reason why arbitrary headers MUST be allowed in
the URL. Headers in the body will serve the same purpose. I would prefer to
err on the side of maintaining the intended semantics of URLs as addresses,
rather than arbitrary property lists.

In retrospect, the first use of "?" probably opened the door for feature
creep as parameters quickly overshadowed the locator aspects of the URL. Once
the CGI mechanisms were established for tagged inputs from the client browser
to the http server, there was a clean extensible path for arbitrary
attributes to be exchanged.  Hidden fields completed the loop for the server
to send back additional meta information to the client browser. Beyond simple
attributes, it would be good to support multi-part documents in a clean
bi-directional manner.