RE: Proxies and XML request parameters

Sure, copy as you will. You really should start beating up on me to get me
to release a document I have put together which collects all the "Why did
you do that?" e-mails I have answered, both in public and private. I just
have about 10,000 things to do and this one hasn't quite ranked high enough.

		Yaron

> -----Original Message-----
> From: Slein, Judith A [mailto:JSlein@crt.xerox.com]
> Sent: Thursday, August 06, 1998 10:24 AM
> To: Yaron Goland; Slein, Judith A; 'w3c-dist-auth@w3.org'
> Subject: RE: Proxies and XML request parameters
> 
> 
> This is a great statement of some rules of thumb for deciding between
> headers and XML entity bodies for request parameters.  Can we 
> put these
> on the Web site someplace as a reference for the authors of the
> remaining specs?  (It would just be a little easier than searching the
> mail archive for them.)  Maybe there are some other guiding 
> principles,
> too, that suthors should keep in mind.
> 
> --Judy
> 
> 
> > -----Original Message-----
> > From: Yaron Goland [mailto:yarong@microsoft.com]
> > Sent: Tuesday, August 04, 1998 10:07 PM
> > To: 'Slein, Judith A'; 'w3c-dist-auth@w3.org'
> > Subject: 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 Monday, 10 August 1998 21:08:47 UTC