20131013

Problem ID: 7734956177663763342
Entered by: Ben Simo
Is there a problem here?  

Healthcare.gov chokes on its own cookies

After signing up for an account on Healthcare.gov, I was unable to login. Each time I tried to login, I got a blank page. After many unsuccessful attempts over a span of many hours, I then tried a different browser, and successfully logged into the system. Then after some use with a browser, login attempts resulted in a blank page.

Searching Twitter revealed that many others were tweeting about having the same problem. The response they got from Healthcare.gov was the same as I had received when I contacted support: that glitches were occurring due to a large number of users on the site, and that I should be patient and try again later -- preferably in early morning hours when there was less site traffic.

Not being so patient, I compared the network traffic of the browsers that could successfully login to those that failed. Those that failed returned an HTTP 400 (Bad Request) error for the userprofile request; while those that succeeded returned an HTTP 302 (Moved Temporarily) status.




HTTP 400 means that either the URL or the request header sent by the browser to the server is malformed. Request headers contain information about the browser's capabilities and cookies. Cookies are small pieces of data placed in your browser by a server in order to identify you and your activity on a web site.

The userprofile URLs for both the working and the failing logins were identical. However, the cookies were significantly different. The total size of the cookies was much larger on the browsers with the failing logins -- specifically a couple cookies that contain information about activity on the LEARN side of Healthcare.gov.

For example, one of my browsers that failed to login was sending requests that were over 4600 bytes:

GET /marketplace/auth/userprofile HTTP/1.1
Host: www.healthcare.gov
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36
Referer: https://eidm.cms.gov/successffmeng.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie:
JSESSIONID=[47-byte value];
optimizelyEndUserId=[35-byte value];
querystring=[31-byte value];
qa-complete=[152-byte value];
quickAnswers=[315-byte value];
optimizelyCustomEvents=[113-byte value];
history=[1048-byte value];
language=[30-byte value];
optimizelySegments=[175-byte value];
optimizelyBuckets=[6-byte value];
akaau=[46-byte value];
_ga=[27-byte value];
__utma=[56-byte value];
__utmb=[25-byte value];
__utmc=[9-byte value];
__utmz=[106-byte value];
__utmv=[144-byte value];
_chartbeat2=[53-byte value];
_chartbeat_uuniq=[1-byte value];
PRUM_EPISODES=[478-byte value];
AKSB=[478-byte value];
ObSSOCookie=[540-byte value]

(In the above example, I replaced the actual cookie values with their size.)


From the information in the response headers from the server, I learned that the userprofile request is handled by an Apache Coyote server. A quick web search revealed that Coyote's default maximum HTTP header size is 4096 bytes.

So, I edited my cookies down until the full header of the userprofile request was under 4096 bytes, and my browser that had been failing to login successfully logged me into Healthcare.gov.

The cookies created by the LEARN side of the Healthcare.gov site (combined with all the tracking cookies), caused the total request header to become too large for the GET INSURANCE side's user profile page to handle. The site is choking on the cookies it generates.

So, this login problem appears to have nothing to do with the number of users on the site. The problem is due to the amount of activity done on the site by an individual user. Those who did not do enough to make the LEARN side of the site's cookies large enough to exceed the 4096 byte limit could successfully login. Those who did a lot of browsing of the site could not login. Clearing cookies will temporarily fix the problem.

If you are having trouble logging into Healthcare.gov, try clearing your browser's cookies.

All those phone and web chat support people telling people to be patient and try again are not addressing the problem. They are only giving users more reason to become frustrated with something that is not related to system load.

Perhaps there are other reasons that others aren't able to login. For me, it appears to have been the size of the cookies.





UPDATE 11/04: I am once again encountering this problem. Deleting the history cookie that gets generated while browsing the LEARN side of the site temporarily fixes the problem.

  Edit

7 Comments:

October 14, 2013 at 1:51 AM  
Comment ID: 2543166550727521220
Written by: Ben Simo

And after viewing only a few more info pages in the LEARN part of the site, I was once again unable to login. Deleted some cookies to put the total header size under 4k, and I can login once again.

October 14, 2013 at 9:04 AM  
Comment ID: 6693643828359321277
Written by: Calkelpdiver

Ben,

When are you going to submit your bill for Testing Services?

Jim Hazen

October 20, 2013 at 10:39 PM  
Comment ID: 8579848297492623674
Written by: Justin Hunter

Ben,

These are impressive bugs you're reporting. Thanks for sharing not only the bugs themselves but also your background investigations into what caused them.

Justin

October 21, 2013 at 8:48 PM  
Comment ID: 3188930235168355337
Written by: Jim

You are right on with this but clearing cookies doesn't work if the site is on the users favorite list (as it was mine).IE preserves data and cookies for favorite sites. Easiest thing to do is delete the favorite, then delete cookies and make favorite again if desired.

March 31, 2014 at 9:52 PM  
Comment ID: 8360653675926868820
Written by: Singingway

Hey Thank you for this! My profile came up blank until I cleared the cookies for the healthcare.gov site. It worked on deadline night March 31st, 2014 which means that the same thing is still happening! Please try to get this information to the website managers. People are waiting in line unnecessarily. In addition, the "wait here" page tells you to do things on the LEARN side while you wait, which makes the problem even worse!

October 3, 2014 at 7:44 AM  
Comment ID: 7892084944906996021
Written by: Anonymous

I'm still having all these problems. I am in the middle of a new revised application and cannot get back into the site no matter what I try to do so I can complete my application.

October 7, 2014 at 9:35 PM  
Comment ID: 8516809815526536244
Written by: Anonymous

Ran into this problem today. Amazing how this remains an issue after a full year...

Post a Comment