Request header cookie exceeds server limit with relayState="ss:mem"

[Jeremy Shapiro]

On Wed, Feb 17, 2016 at 9:16 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 2/16/16, 9:26 PM, "users on behalf of Jeremy Shapiro" <
> users-bounces at shibboleth.net on behalf of jnshapiro at gmail.com> wrote:
>
>
> >I'm getting a 400 response to a shibboleth protected server due to the
> Cookie header exceeding the 8k limit.  My cookie header contains 8200
> bytes, 56 instances of shibpost and 56 instances of shibstate.
>
> That doesn't sound like any recent version, there were bugs a while back
> with cookie cleanup and limits on the number.
>

This is shibboleth sp 2.5.1.

>
> > Examples include:
> >
>
> >_shibpost_1455658465_74a8=ss:mem:5366a7205e99c782f1361815f08e2bf885af6dd43732eca7c0fac2d087e693c3
>
> I don't understand that either, that doesn't seem like anything it would
> be doing. The POST preservation is for application form interruption, I
> don't understand how it could be saving off that value.
>
> >_shibstate_1455674546_de35=https%3A%2F%2Fmyapp.example.com <
> http://2Fmyapp.example.com>%2F
>
> And that makes no sense since that would be used if the cookie-based relay
> state option were used.
>
> >The sp is using relayState="ss:mem".  The documentation states that if I
> were using relayState="cookie" my request should automatically be capped at
> 25 instances.
>
> Yes, that's the issue I was thinking of.
>
> >Is what I'm seeing expected behavior when using relayState="ss:mem"?
>
> No, I have no idea what you could be seeing with all that strangeness.
> Makes no sense to me.
>


I'm unable to reproduce the problem of the number of cookies increasing.
With a new session,  I now get three cookies _shibpost, _shibstate, and
_shibsession.  Are you saying that's unexpected as well?

  Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160218/9528b727/attachment.html>