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.
10 Comments
Comment
