BaseSAMLMessageDecoder.checkEndpointURI

[Brent Putman]

On 3/1/12 2:06 PM, Zmuda, Matthew R wrote:
> The following is called to get the actual endpoint:
> 
> StringBuffer urlBuilder = httpRequest.getRequestURL();
> 
> Doc's say:
> 
> StringBuffer getRequestURL()
> Reconstructs the URL the client used to make the request. The returned URL contains a protocol, server name, port number, and server path, but it does not include query string parameters.
> 


Yes, correct.



> At this point in time client is at the new URI.


Well, I think the terminology if what is confusing here re: "at the new
URI".  The load balancer may be shuttling the request off to new
physical servers, which have distinct physical names, but from the
client browser's perspective, it's still accessing the original logical
URI, e.g. https://my.domain.com/profile/SAML2/Redirect/SSO.

So it's not really true that, from the client's perspective, it is "at a
new URI".  Unless the load balancer is doing this as an HTTP redirect or
something, but then that's not really the notion of "load balancer" that
we're talking about here.



> So why would it be the server configuration's obligation to report the logical URI when the code is getting the client's URI?
> 


As Scott already mentioned, if a web application needs to generate and
make use of self-referential URL's, for whatever reason, it needs to do
so based on the logical URI's that the client should see.  Since
applications most commonly simply use info from the web server
environment to construct this self-referential URL, web servers like
Apache and Tomcat often have specific support to override the scheme,
domain name and port that it tells to applications.  For environments
like load-balanced environments, one has to make use of these features
to get the right self-referential URL data to the application.