Re: SOAP and the Web architecture

PPS - most caching proxies consider URIs with query arguments
automatically uncacheable. Other URI characteristics are used as
input to freshness heuristics as well (e.g., presence of 'cgi-bin',
'.gif', etc.). None of this is standardized, of course, but is
allowed by the HTTP.

One of my side projects is to try and come up with a standard
freshness heuristic for HTTP and get a bunch of vendors on board, but
this has been on the back burner for a while.


On Tue, Aug 28, 2001 at 03:02:35PM -0700, Mark Nottingham wrote:
> 
> Well, in the case of Squid, changing the max request-URI size
> requires a change in a .h and a recompile.
> 
> Figures that I see say that anywhere between 15% and 30% (depending
> on who you believe) of the HTTP traffic on the planet goes through a
> caching proxy (note that this doesn't include other HTTP
> intermediaries, just caching proxies). Many of these are very old
> products, indicating that they're deployed in a 'fire-and-forget'
> manner.
> 
> Considering this, as well as the difficulty of coordinating this
> change with all of the intermediary's administrators (who often don't
> care about the user's problems), it doesn't seem likely that we can
> say "Hey, SOAP is cool; please change your deployment and/or code"
> and get universal compliance.
> 
> Things will break, likely for a long time. Whether this is acceptable
> or not is another question. Proxies are run in the interest of access
> providers, not end users, and as a result don't always operate in a
> manner that is transparent and/or friendly to the end users' wishes.
> 
> 
> P.S. HTTP/1.1 defines a status code for 'request-uri too long';
> HTTP/1.0 does not. No major vendor, to my knowledge, has released a
> HTTP/1.1 compliant proxy before this summer; the majority are still
> 1.0 (1.1 is difficult to implement for intermediaries in a marketable
> fashion). Because of this, it will not necessarily be easy to detect
> this failure condition.
> 
> 
> On Tue, Aug 28, 2001 at 02:44:03PM -0700, David Orchard wrote:
> > Mark,
> > 
> > What do you mean by "support" and "requires something"?  If SOAP
> > requires that some, maybe even all software, change 1 parameter,
> > does that count as "not supported"?  It seems to me that if SOAP
> > requires a configuration change, then the software supports it and
> > requires no software change. Certainly a separate download and
> > install isn't required.  I separate and distinguish between code
> > changes and on-site configuration changes, and I'm wondering what
> > you and others think.
> > 
> > Do you classify configuration changes under "suddenly requires" or
> > "support"?
> > 
> > Thanks,
> > Dave
> > 
> > On Tuesday, August 28, 2001 1:38 PM, Mark Nottingham [SMTP:mnot@mnot.net] 
> > wrote:
> > >
> > > > If an arbitrary limitation of the software gets in the way of
> > > > meaningful useful real-world uses then it is lacking a feature
> > > > whether we call it broken or not.
> > >
> > > I don't think it's arbitrary; implementations need to protect
> > > themselves from overflow attacks, etc. Of course, if the world
> > > decides that longer URIs are a good and useful thing, fine.
> > > However, one of the ideas behind having HTTP bindings for SOAP is
> > > that it will be able to use the existing infrastructure (re-use
> > > existant HTTP stacks, and use HTTP for routing out of the
> > > firewall). If SOAP suddenly requires something that a good part
> > > of that infrastructure doesn't support, we lose a lot of value.
> > >
> > >
> > 
> > <snip/>
> > >
> > > Cheers,
> > >
> > >
> > > --
> > > Mark Nottingham
> > > http://www.mnot.net/
> > >  
> > 
> 
> -- 
> Mark Nottingham
> http://www.mnot.net/
>  
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Tuesday, 28 August 2001 18:34:49 UTC