Issue with large HTTP headers for ECP authentication

Daudt, Carl crdaudt at
Wed Dec 12 09:31:44 EST 2018

Scott, I might have mislead you and other readers to infer that the size of the shib_idp_session_ss cookie was growing over time.  I described the cookie as being "bloated", but did not mean to imply that the cookies are continuing to get larger (although at the time of my original post I wondered if that might be the case).  We have not observed an increase in size over time, but we have observed that the cookie was much larger for some users than for others.  We now understand was caused by having the entire LDAP record encapsulated in the cookie.

Based on Peter's comments, we reconfigured the changes that we made to and attribute-resolver.xml:
(1) In, we re-modified idp.authn.LDAP.returnAttributes as follows:
    idp.authn.LDAP.returnAttributes = passwordExpirationTime,loginGraceRemaining
(2) Also in, we removed the definition for idp.attribute.resolver.LDAP.returnAttributes that we had previously.  It was only necessary if used in the LDAP data connector (see my next point)...
(3) Then in attribute-resolver.xml, we removed the <ReturnAttributes> line in the DataConnector for LDAP.

Scott and Peter, we are most appreciative of your responses.  We are still in a testing phase for our Office 365 configs, and are still learning as we go.  My hope is that if other readers encounter an error in their shibboleth (or tomcat) logs stating that the maxHttpHeaderSize has been exceeded, they will have some comprehension of what might be causing the large headers and have one idea of what might be causing the issue.


-----Original Message-----
From: users [mailto:users-bounces at] On Behalf Of Cantor, Scott
Sent: Tuesday, December 11, 2018 8:23 PM
To: Shib Users <users at>
Subject: Re: Issue with large HTTP headers for ECP authentication

On 12/11/18, 6:35 PM, "Cantor, Scott" <cantor.2 at> wrote:

> I hadn't realized the LDAP authentication results included the
> attributes returned during authentication, hadn't considered that
> possibility. But even if it does, why would that bloat the cookies? They'd have some fixed size increase of course, but it wouldn't grow over time.

This seems like the most interesting aspect to me. I think the client here would have to be doing something unusual and inconsistent, like returning that one cookie but not others (in particularly the main session cookie), causing it to keep issuing new sessions and storing them in the blob without overwriting or replacing the existing session records.

If that's true, you're buying time but not really fixing the problem with this solution, it should eventually creep back up, though it's possible that would be counteracted by the sessions timing out soon enough to avoid it being noticeable. But it's still not good behavior by the client, certainly.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at

The information in this communication is intended solely for the individual or entity to whom it is addressed. It may contain confidential or legally privileged information. If you are not the intended recipient, any disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited, and may be unlawful. If you have received this communication in error, please notify us immediately by responding to the sender of this email, and then delete it from your system. Taylor University is not liable for the inaccurate or improper transmission of the information contained in this communication or for any delay in its receipt.

More information about the users mailing list