ERROR XMLTooling.ParserPool

Cantor, Scott cantor.2 at osu.edu
Fri Sep 21 11:32:44 EDT 2012


On 9/21/12 11:13 AM, "Andy Bennett" <andyjpb at knodium.com> wrote:
>
>Everything's over HTTPS so I might have to set up Some Infrastructure.
>It's definitely reproducible tho so I'll see what I can cobble together.

I think you can get Wireshark to trace that if you give it the key.

>> Is it failing during the POST step, or are you getting logged in and
>>then
>> seeing the error during the next request? What do the logs say?
>
>It's during the POST to SAML/POST.
>
>Is there an easily available knob for this? I posted everything that got
>logged: it was just those two lines.

That's all I was wondering. But you're saying that it works if you somehow
refresh the page, meaning I guess you resubmitted the POST. I can't see
how that's possible. Same data should result in the same error. So I have
no idea. Are you sure all your packages are 2.4.3 here? Not some mixture
with the FCGIs older or newer than shibd?

I didn't think Debian even packaged the FCGI stuff. So that makes me very
suspicious right there. If that's so, how did you get it built?

>OK. I'm more suspicious than that tho' because it only happens between
>two logins to different IdPs: never on the first login and I can't think
>how the state would be transferred between the IdPs... so there must be
>some state in shibd or the FCGIs that's causing trouble.

There's no state that would be in shibd, it's failing on messages to shibd
that are just being parsed and then erroring out. Whatever the bad
character(s) are they must be coming from the FCGI half or the client
itself.

The other thing that triggered errors of this sort were mixing versions on
the two sides of the remoting. For example, updating the Apache module and
not shibd or failing to restart both after an upgrade. That's why I'm
suspicious about the packaging.

-- Scott




More information about the users mailing list