Reevaluate behavior when cookie parsing fails

[rynowak]

Related to issue #390 but this topic is more about what the behavior should be when you're in this state.

I ended up with request cookies like the following for http://localhost:5000/:

__RequestVerificationToken=xhhkbQ7Vw0bBpyKt924bA4mEwn-xqrEj8w_Icr5Z2LQnXtugI8qt_glxLRAP3KPQR8RGBUukjfQzPOFCO2sffThjcUmtdgSkzn2iZ4NoObo1;
rm3EK3lo-DQ=CfDJ8DZcqGjS2eNPqurEN8WnNPUoyWWl9b3SROeJgbx_QsBsWViYvx7lI8jIQf5nv9_3B8zVdvmQdTYuqACH5p9Lx07aH8sctN-kt6CJTA4pp39O2Yymvs7M2IBx8eeTqeEn5uXh9_yV66f6dqK4l78r7dQ; 
Sample=36; 
ipt={"v":{"L":3},"pt":{"d":3},"ct":{},"_t":44,"_v":"2"}; 
.AspNet.Session=f5b61640-9efc-a9f8-32c1-6291f903f795; 
BQFxCZqo5n4=CfDJ8GVk6iB7ymZKmY1csOqk7Cds8G0Hd8XFeWgB9u4RB0r73u2gJvYuQmjGY2vn8WtGvFFKwUOLS3LVlkIxH9YmvQBopm69anm0VuXYBePCzYMYRruxRQ9ma34AAZSI76o3eV6cV0xsU3MYytMgTkC_f1U; 
eZYsIZozZe4=CfDJ8GVk6iB7ymZKmY1csOqk7CeNhzXg8fanKIOAcxGcBWXzm5AYBDlOgfSNHG8dLtWG2bFucr_PNhmjyEybiZQgGrdL2CEmvrhxR4MIoh6FgXdcx7N6OHL0tgDn520ud3i-ODYlXGr3aYT-5Eg3M8ulwvc;
XSRF-TOKEN=CfDJ8GVk6iB7ymZKmY1csOqk7CfYDif53fpXVX_mfM1SVKdA4fDDMi3rx98lBVks-zLiGjMv3j6SgAEHMe4VwKqMw5WCdJObXVgF1kTLA62U8SQJ2eLK2cv4vhcmlixQN3dhtOt_yeiPYtAkipDlhPUWiAg

and I was mystified about what to do when antiforgery wasn't working. At some point in my otherwise squeeky-clean past, I was hacking on something that added ipt={"v":{"L":3},"pt":{"d":3},"ct":{},"_t":44,"_v":"2"}; to my cookie store, and it effectively 'poisoned' local development for me with anything that relies on cookies in our stack.

What happens when you get into this state is that there's no indication that the cookie header was consider invalid, the cookie collection is empty, and no exception is thrown.

[Tratcher]

Note: because cookies are domain specific you would only see this kind of cross app contamination on a dev machine (e.g. localhost).

[lodejard]

Now that you mention it - you could also see cookie contamination when your web app is part of a compound site behind a layer 7 network load balancer

[lodejard]

Or similarly on IIS with vdirs

[riegelj]

I am in favor of changing this behavior. I am experiencing an empty cookie collection as a result of cookies that are created from a 3rd party web site that we use regularly within our company. If the 3rd party web site is run I loose the ability to get any cookies in our web site.

[riegelj]

just a note: I see the cookie contamination in other environments - not just localhost.

[muratg]

Moving this to Backlog as we will be in RC2 ask mode very soon. If you feel strongly about this issue, please ping me.

[riegelj]

This is a pretty big issue for us. We have a large domain with many applications some third party like the one that is crashing the cookie parser. In our case we are using a cookie to authentication tokens and not having it available reliably means we can’t authenticate our web api calls.

[Tratcher]

Please share sample (redacted where needed) cookie headers containing a mix of valid and invalid values you've observed. I'll see how forgiving we can make the parser.

In the case of cookie1=valid1; cookie2=invalid2; cookie3=valid3 it's easy enough to return cookie1 but returning cookie3 can be a challenge. Should we even try to return cookie2?

[riegelj]

I sent fiddler loges to the support agent SR number 115121713508104 which he used to reproduce the problem hopefully they should still be attached. My need would be if cookie2 is bad we should still get cookie1 and cookie3 -- In a perfect world you would return me what you could for cookie2 maybe just the raw string value.

[Tratcher]

Thanks @riegelj, I was able to retrieve your sample and successfully parse it with my changes. I still skipped the invalid value though. Having spaces in the value is a whole new flavor of invalid...

[riegelj]

Roger that, Thanks!