Why does Discourse have such large cookies? Is there a reason for it? Is there a way to decrease their size? I was poking around in the Discourse admin dashboard, and I suddenly got a 400 Bad Request error back from /sidekiq/retries 400 Bad Request Request Header Or Cookie Too Large I checked the request and, sure enough, my browser sent a huge Cookie header to my Discourse server. Why? Cookie: _t=403b8203003bdaf522679e0b6c17605f; rack.session=BAh7C0kiD3Nlc3Npb25faWQGOgZFVG86HVJhY2s6OlNlc3Npb246OlNlc3Np%0Ab25JZAY6D0BwdWJsaWNfaWRJIkU4NjY1Y2Y3MjU4OGYzZjk3MDUyMDdhNzhh%0ANzc4OGZlZTRhNzFkY2JjMzA4NDAyNjY3MWMwNmFhYzc2Zjg0NWIyBjsARkki%0AEF9jc3JmX3Rva2VuBjsARkkiMW9KNk83S1B5ZUVaR0I2WnBxckxISzNxbEla%0AdGRyVXNCUnc3d2JiaVorVmM9BjsARkkiFnNlY3VyZV9zZXNzaW9uX2lkBjsA%0AVEkiJWM3YWJjYTk3OTRlNTExNTllZWUyMTBkYmVkNDgzNDc4BjsARkkiCmZs%0AYXNoBjsAVHsHSSIMZGlzY2FyZAY7AFRbAEkiDGZsYXNoZXMGOwBUewZJIgxy%0AZWZlcmVyBjsAVCJPaHR0cHM6Ly9kaXNjb3Vyc2Uub3BlbnNvdXJjZWVjb2xv%0AZ3kub3JnL3UvbWFsdGZpZWxkMC9tZXNzYWdlcy9ncm91cC9hZG1pbnNJIglj%0Ac3JmBjsARkkiMVRuUHJ6TTMzUHZqcG9oditwdTRyem9HeDUxQnAwL0psci9z%0AYkFZWkpxdkU9BjsARkkiDXRyYWNraW5nBjsARnsGSSIUSFRUUF9VU0VSX0FH%0ARU5UBjsAVEkiLTk3MDJkMjYxMmJlZmM5N2U4YTIzMDVkNjU0Y2IwOThmMmQ4%0AYTI1NTUGOwBG%0A--e602081dddcd88bdb269034e7acb8c582665be0e; _forum_session=V2dWY0FGVGhsMDVtcmdmNVdicXpJVkxnVC9vUWpkeVdpSHRIYWZaVVhVZDUxcFlRdTh4bHFTQVRRcUpGR3pMRGZ1M3NGeENzUloreGdEWEtQS2Z2WDJKNFZUeXRjNXlTTTRHVzJsQzBORzVuSW9NNHg3UHhwNzdUNFlCNGVvcytkSjA1b0d3NlM3czNlTlFxMEloQmNOYzMxTm5mYW4zaWlMSkpxWXZiZDlBRFJnR3dxTkphM0ZtZmk4bGswcUdzYm94b3pkUk0zTG5sMjhqNkxYMnZqMjJPYkhzMGFLM2JWZzBCRXpFa2wyZm1HbUl3REVzd3c5MmhRMG5YMkFJV0t6Z2ZPRlI2bVpOQWJlZWJQd2pyclEvdmVmWUlsYkxyU0EzcDFaZkRpOU14SVptMk01TjZtZlNXa2VUQnFaaGZpNDlaQVBnY0RCS2ZlbVBiQWt3S2lSeHcvY0g2WUlXOTRLejh2dVhhcDFoRXVobUdRMnJvcjhtRTkxZjZCYXM1eDd2NU1rZ3duRy83VVhVSG5Ua3BIOTJoQ1orY2dlMjh2M0Fuc0lwb3p3ckVtaXhxaDkxT2E1YnEvbnBWTVlCaXd4Q2h6eTd5Ty84WUYzeUVFbE9KSXhadXZ4aUw1TmVoSEE0cW9YSHA3VTJoK3NtdktrL09qcDVxMnR5bFhhUmU1dDMzT0ZBUGxBRXBZVHB5WlNtODM2YzBsOVRkc3RpMmFFSW5COEhyRjFTY2ZCZk5VbUpYN2JzYlh6SGNGWEs2dWhQUkJnMmd4K3ZJQUFkQThwa2tOMnI3Vi9qMFo5RE5XWWxxRXFTTTNmRnJKU294aStKZFJ4NHRDTGh4WXR1Z3F5QWU3ZkMxTXBpMzcvYTd5QkRwajNjcDF6SWdFSkdqNDJlMk0vYW1mODNEdDhZSk9jbzRPRHNhZUYzNjVOWkErbVJSNG82VnhRL0FFRUtWbE1uQWFPa0JqQUFmZ21iL0YvSFIrM1dlSDNvPS0tK1pMRzNmRjA4L3c4VTkrVEllYmNQZz09--325ca2e886afaefffeb6174c99776f91fefd4292 The above Discourse cookie string is 1,962 characters long! For comparison, the cookie header sent to my Mediawiki site is 122 characters long, including my username, user id, and session id. The Mediawiki session id is 32 characters long, but Discourse appears to have two session ids: rack.session is 813 characters long and _forum_session is 1,075 characters long. Please help me to understand why a simple uid needs to be so long. Can I configure Discourse to use a shorter session uid? Does such a request make sense? What is stored in that string? Is it possible to make it smaller? Specifically, what component of the Discourse software is rack.session used for? And what is _forum_session used for? Of course I can just bump up the nginx config limits, but I’d like to keep them reasonably low unless there’s a strong requirement to increase them.

I support auditing our session cookies and maybe just moving to default use our redis backed session that auto expires which is better anyway. @david any thoughts here? lib/secure_session.rb 42758379b # frozen_string_literal: true # session that is not stored in cookie, expires after 1.hour unconditionally class SecureSession def initialize(prefix) @prefix = prefix end def self.expiry @expiry ||= 1.hour.to_i end def self.expiry=(val) @expiry = val end def set(key, val, expires: nil) expires ||= SecureSession.expiry Discourse.redis.setex(prefixed_key(key), expires.to_i, val.to_s) true This file has been truncated. show original

This shouldn’t be a problem for someone using our official install, just for people using badly configured proxies right? Also HTTP/2 header compression makes for this headers to be uploaded just once in the entire user visit.

[image] Falco: This shouldn’t be a problem for someone using our official install, just for people using badly configured proxies right? Depends, plugins that use session heavily can be impacted, its also a hygiene thing, nicer to keep all this secret info on the server instead of encrypted on the client.

[image] Falco: just for people using badly configured proxies right? Yikes, this tuning was done intentionally for security; it’s not a “badly configured” proxy. Tuning down the following nginx directives is commonly done as part of hardening nginx (to address availability, rate limiting, DOS, etc): limit_conn_zone limit_conn limit_req_zone client_body_timeout client-header_timeout ssl_* add_header # SAMEORIGIN/XSS-Protection/CORS/CSP client_body_buffer_size client_header_buffer_size large_client_header_buffers client_max_body_size The settings we use in our nginx config work fine on all our existing sites. The problem here appears to be that Discourse stores unnecessary client data in the cookie, where imho the only thing stored in the cookie should be just a few unique identifiers that the server can use to access that data server-side. [image] sam: I support auditing our session cookies and maybe just moving to default use our redis backed session that auto expires which is better anyway. @david any thoughts here? Thanks Sam. By “moving to default use redis” are you suggesting that it’s currently possible to move the data stored in the session cookie to redis with a configuration change? Or would moving this data out of the session cookie to the server necessarily require a code change?

[image] maltfield: it’s currently possible to move the data stored in the session cookie to redis with a configuration change? Nope, requires a code change [image] maltfield: Tuning down the following nginx directives is commonly Why is 10k worth of headers a problem? They are compressed, if 10k of headers is a problem why is 10k html payload allowed?

[image] maltfield: Tuning down the following nginx directives is commonly done as part of hardening nginx (to address availability, rate limiting, DOS, etc): limit_conn_zone limit_conn limit_req_zone client_body_timeout client-header_timeout ssl_* add_header # SAMEORIGIN/XSS-Protection/CORS/CSP client_body_buffer_size client_header_buffer_size large_client_header_buffers client_max_body_size Note: I’ve also had to override my hardened nginx config’s large_client_header_buffers directive to get Discourse working. Specifically, I use large_client_header_buffers 2 1k for all my other sites’ nginx configs. But this causes a 414 Request-URI Too Large error from /admin/reports/bulk?XYZ – where XYZ is actually 1,019 characters long! This was fixed by setting large_client_header_buffers 4 8k; in my Discourse nginx config’s server{} block, which overrides the global directive and restores the directive to its default value for Discourse Module ngx_http_core_module For better interoperability of Discourse installs through popular hardened web servers, network firewalls, and web application firewalls, I urge the Discourse developers to consider using POST for such long query strings.

[image] maltfield: from /admin/reports/bulk?XYZ That is a very very narrow use case.. specific to admin.

For someone who is not a backend engineer, what is the fix for this? We are getting a lot of reports of this error over the past month on the Webflow forum. Recommending a visitor clear their cookies/cache or use incognito mode has worked but not ideal. Any advice on fixing this for our instance of Discourse would be much appreciated.

[image] Matthew Munger: We are getting a lot of reports of this error over the past month Can you link an example? This problem in OP is about self-hosting Discourse, so I do not follow how can it affect a hosted instance like the one you linked.

Discourse session cookies (400 Request Header Or Cookie Too Large)

Product Support Self-hosting

sam (Sam Saffron) December 30, 2019, 9:29am 7

Nope, requires a code change

Why is 10k worth of headers a problem? They are compressed, if 10k of headers is a problem why is 10k html payload allowed?

Topic		Replies	Views
Add path to cookie Development	48	8385	September 5, 2025
Setting the session token '_t' on the entire domain, not just my subdomain Development	6	5622	May 1, 2016
Purpose of Cookie '_t' Product Support	1	948	November 19, 2020
Session Timeout Data & reporting	66	10720	January 4, 2025
Sessions are very short, even though default session length of 60 days is in place Product Support unsupported-install	2	182	July 14, 2025

Discourse session cookies (400 Request Header Or Cookie Too Large)

Related topics