Re: SOAP and the Web architecture

It's implementation-specific. Generally, there are multiple
per-request buffers allocated for URIs, and memory is *very* precious
on HTTP intermediaries.

Squid [1], the most well-known (and widely deployed) caching proxy
currently defaults to 4096 bytes. IIRC, older versions (which are
still in service in some ISPs, .edu's, etc.) limited it to 1024 or
2048.

Commercial implementations (the biggest are roughly: Network
Appliance, Inktomi and Cisco) will likely have similar limitations.
I'll ask a few people I know...

Also, consider that application-layer firewalls and gateways (e.g.,
Checkpoint Firewall-1), etc. will have similar limitations, as well
as their own idiosyncracities. There are a *lot* of semi-broken,
small-vendor, special-purpose intermediaries out there as well.

[1] http://www.squid-cache.org/




On Tue, Aug 28, 2001 at 12:46:11PM -0700, David Orchard wrote:
> We all know that there are intermediaries, but I'm curious about what the 
> actual limits are.  I found one for Apache as a server, but not as an 
> intermediary.  It seemed pretty trivial to remove the impediment in Apache.
> 
> Mark, can you shed some light on what specific limitations there are?
> 
> Where I'm going is that limits on URIs but not on message length is 
> obviously because of the brower based web.  I'm not sure that this should 
> preclude us from considering non-browser interactions through GET though.
> 
> Cheers,
> Dave
> 
> On Tuesday, August 28, 2001 12:30 PM, Mark Nottingham [SMTP:mnot@mnot.net] 
> wrote:
> >
> > Exactly. Most (if not all) intermediaries impose limits on URI
> > length. It's not just origin servers and browsers out there...
> >
> >
> > On Tue, Aug 28, 2001 at 09:59:58AM -0400, Hugo Haas wrote:
> > > * Scott Cantor <cantor.2@osu.edu> [2001-08-27 23:47-0400]
> > > > > Arguable. What spec. restricts the complexity of data sent
> > > > > through GET?
> > > >
> > > > No spec, merely (nearly) every real world implementation.
> > >
> > > Actually, I found some interesting text in RFC2616[1] which I would
> > > like to have more context about:
> > >
> > >   10.4.15 414 Request-URI Too Long
> > >
> > >    The server is refusing to service the request because the 
> Request-URI
> > >    is longer than the server is willing to interpret. This rare 
> condition
> > >    is only likely to occur when a client has improperly converted a 
> POST
> > >    request to a GET request with long query information [..]
> > >
> > > Maybe I am going to find some info about that in the references sent
> > > out by Larry.
> > >
> > >   1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.15
> > > --
> > > Hugo Haas - W3C
> > > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - 
> tel:+1-617-452-2092
> > >
> >
> > --
> > Mark Nottingham
> > http://www.mnot.net/
> >  
> 

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

Received on Tuesday, 28 August 2001 17:40:55 UTC