RE: SOAP and the Web architecture

David Orchard wrote:
> SAML problems with GET length is only because of having a 
> browser binding.

Well, yes, but I fail to see the general usefulness of some of SAML (and
all of Shibboleth) without one. ;-)

>  Every articulation I heard was because of browser constraints, ne'er
> a server constraint to be seen.  Presumably if one used a better
> client library for connecting to servers, such as the case in 
> non-browser/server cases, there would be a different but higher length
> restriction.

Yes, and this is basically the case with servers. The limit tends to be
longer, but it's not infinite, or even particularly large. The issues
raised may have been client-only, but they aren't the only issues. The
Shibboleth calls discussed both.

I agree, however, that in the absence of a browser as the front end, the
limit may be longer. I'm not sure how that really helps. If I know
there's a limit at all (that's not really high anyway), I'm not going to
risk it as a developer.

> After some poking about on Apache, I found some interesting 
> configuration items.  Of particular interest is the apparent 8k max on
> a URI length.  The documentation describes longer request lines as
> abnormal client request behavior ;-)

Sounds about on par with what I've seen elsewhere.

> It seems to me that Apache servers that are targetted to 
> application clients could easily change 1 variable and much longer
> GET + URI requests could be allowed, especially given that at least 2
> GB bodies are supported. 
>   Surely a single default for Apache server can't be the 
> reason for not using GET requests from non-browser client apps to
> servers.

It's not at all clear to me that only non-browser clients are of
interest here over time, but even if it were, Apache isn't the only web

It's not as though I'm saying it can't be done; obviously all the
clients and servers can be modified to relax the limits. Will they and
when are the relevant questions.

-- Scott

Received on Tuesday, 28 August 2001 10:12:47 UTC