RE: Proxies and XML request parameters

The rule was "It goes in the header unless you have a damn good reason to do
otherwise."

Put in more detail:

If     (it involves cachability it goes into the headers) exit; 
elseif (it is likely to be something a firewall would want to examine it
goes into the headers) exit;
elseif (it must be used with a method that already has a defined body then
it goes into the headers) exit;
elseif (it encodes information that is very likely to be expanded on later
then it goes in the body) exit;
elseif (it has potentially unlimited length then it goes into the body)
exit;

The second to last rule reflects the difficult of encoding the DAV message
model in a header without re-inventing XML for headers. The last rule
reflects the reality that most proxy/firewall implementations will barf if
headers get larger than around 4k. This also effects performance. Once a
proxy/firewall hits content length it can just blindly start passing bits,
which is very fast. If you have mega huge headers you slow down every single
proxy/firewall on the path for info it may not care about.

As always, it is a judgement call.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Tuesday, August 04, 1998 10:22 AM
> To: 'w3c-dist-auth@w3.org'
> Subject: Proxies and XML request parameters
> 
> 
> The issue has been raised here about whether we might be making a
> mistake by encoding some of our request parameters in XML 
> entity bodies.
> The thought is that this may force proxies to read the body of the
> message, something that they should not have to do.
> 
> I guess there are several questions here:
> 
> Are we currently forcing proxies to read message bodies?  Are 
> any of the
> parameters that are now in the message body ones that proxies have to
> know about?  If so, should we make some changes?
> 
> Should we express some design principle for future revisions of the
> spec, about not putting into the message body any parameters a proxy
> might need to read?
> 
> Should we consider a more extreme position (that would require
> significant changes to the current spec):  Never put request 
> parameters
> in the message body?
> 
> Judith A. Slein
> Xerox Corporation
> jslein@crt.xerox.com
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
> 
>

Received on Tuesday, 4 August 1998 22:06:55 UTC