Problem reading MetaData from URL

[Brent Putman]

On 11/7/13 9:59 AM, Adam Portier wrote:
>
> My question is twofold. Could someone who is better at debugging
> Metadata than I take a look at the link I have provided and tell me
> why Shibboleth's parsing engine is choking on the first line? I want
> to have something specific to ask these vendors to look at.

This sounded like a weird one, so I did some debugging.  It displays
fine in a web browser, and it also parses fine for me if I download to
the filesystem and use FilesystemMetadataProvider as well as copy up to
one of my own webservers and use HTTPMetadataProvider.  I didn't delete
the XML prolog, either, so it's not the actual text.

On debug, I did notice our HTTPMetadataProvider was saying when fetching
from their server:

DEBUG HTTPMetadataProvider - Successfully fetched 37bytes of metadata
from http://myreviewroom.com/saml2/metadata

which is odd b/c it has in reality 6600+ bytes. 

So, added a couple of lines of debug output to the provider to see
exactly what was coming back:

DEBUG HTTPMetadataProvider - Successfully fetched 37bytes of metadata
from http://myreviewroom.com/saml2/metadata
DEBUG HTTPMetadataProvider - bytes:
DEBUG HTTPMetadataProvider - Sorry, we cannot support your client.


So it's handing back the literal response body "Sorry, we cannot support
your client.".

So, their web server is at fault.  They must be doing some kind of
validation on some aspect of the request (e.g. User-Agent header), and
therefore refusing to service requests coming from the IdP's HTTP
metadata provider.

So that's what you can tell them.  If they ask, our metadata provider is
based on the Apache HttpClient library v 3.x.  I don't know off-hand
what, if any, User-Agent header it sends.  But IMHO they shouldn't be
doing what they are doing in any case.

Thanks,
Brent