Other than the Firefox on Android issue I haven't noticed anything wrong.

I don't think I've ever seen the "Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit" Error. I'll be on the lookout for it.

And I hit the site using multiple browsers from multiple isp's on multiple operating systems (linux, android, iPadOS and windows.) With and without using a VPN.

Maybe Blues News or your isp is getting dos'ed by toothbrushes.

Check your cookies, Blue. Cookie data is sent in request headers and is almost certainly what's triggering the error. Looking at the request the browser is making to load the comments page for a post, I see two cookies called "chatbear-session-1" and "chatbear-session-2" and the first one has quite a bit of data.

You can see this by opening up your browser dev tools, Network tab, then load a page and select the first GET request, go to the Cookies tab, and check the request cookies. At least this is how it's found in Firefox - other browsers are probably similar.

100% what Tom said.

It's what I tried to explain last October too, when you first mentioned this issue.

The too long request header in these cases is most likely the Cookie header. Something managed to set too many / too long cookies for your domain, likely amassed over an extended period of time. Your browser simply attempts to send every single non-expired cookie matching the origin and path you are visiting with every request, all concatenated in a single header line.

Tom wrote on Feb 7, 2024, 14:09:
Check your cookies, Blue. Cookie data is sent in request headers and is almost certainly what's triggering the error. Looking at the request the browser is making to load the comments page for a post, I see two cookies called "chatbear-session-1" and "chatbear-session-2" and the first one has quite a bit of data.

We already looked into this, a request header field can be 8KB max by default, cookies can be 4 KB max, and the board code safely truncates the session cookies (per forum) to about 3800 bytes. We use about 20 cookies for all site functionality, and external providers perhaps a dozen, so that shouldn't be too much AFAIK. Unless that all goes in a single header, I guess... Anyway, we need to look further into this.

Tom wrote on Feb 7, 2024, 14:09:
Check your cookies, Blue.

I think it is the cookie. I did have the same problem several months ago right about the same time as Blue, like a day before he posted about it. Deleting the site cookies had resolved it. I thought the site was down for at least a day until I started to check my end.

I thought I posted about it then but can't seem to find it.

fds wrote on Feb 7, 2024, 14:39:
It's what I tried to explain last October too, when you first mentioned this issue.

Ow, we... uhm... forgot about that. And I almost never read the news forum to begin with. The concatenation may be the cause, then.

Frans wrote on Feb 7, 2024, 14:40:
Unless that all goes in a single header, I guess...

Cookies indeed get concatenated, and all go in a single header line, on requests. Every single ad, tracking etc network that might set cookies locally, are all fighting over that same space.

It could totally be some external cookie causing the problem, yeah.

Another thing to consider is, you may have your web servers configured with some max (default or otherwise), but are there any other servers in the loop that could have a different max and be returning this error? Intentionally causing the error and looking for logs may shed some light.

fds wrote on Feb 7, 2024, 14:39:
100% what Tom said.

It's what I tried to explain last October too, when you first mentioned this issue.

Dang, my ability to forget things gets sharper all the time! Sorry about the whole pearls before swine nature of this.

The good news is that this brings it back up, since it never did get addressed on our end, so Frans and I are discussing this now. Thanks (x2).

Tom wrote on Feb 7, 2024, 15:02:
It could totally be some external cookie causing the problem, yeah.

Aware of that, but given that cookie chatbear-session-1 for a frequent visitor of the news forum is maxed out around 3800 bytes, that leaves less space for all the others combined. I guess I'll lower that limit to 3600 and then we'll have to see how it goes. It just means fewer remembered threads for everyone.

Tom wrote on Feb 7, 2024, 15:02:
Another thing to consider is, you may have your web servers configured with some max (default or otherwise), but are there any other servers in the loop that could have a different max and be returning this error? Intentionally causing the error and looking for logs may shed some light.

Blue's requests received HTTP 400 responses (though I'd expect 431) so yeah, it was our server throwing the errors, not an ad provider or somesuch.

fujiJuice wrote on Feb 7, 2024, 14:44:

Tom wrote on Feb 7, 2024, 14:09:
Check your cookies, Blue.

I think it is the cookie. I did have the same problem several months ago right about the same time as Blue, like a day before he posted about it. Deleting the site cookies had resolved it. I thought the site was down for at least a day until I started to check my end.

I thought I posted about it then but can't seem to find it.

here it is
,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.

Fricken cookies, I guess that's why the first thing anyone says is to delete your cookies if you're having a problem with a site.

Frans wrote on Feb 7, 2024, 15:16:
Aware of that, but given that cookie chatbear-session-1 for a frequent visitor of the news forum is maxed out around 3800 bytes, that leaves less space for all the others combined. I guess I'll lower that limit to 3600 and then we'll have to see how it goes. It just means fewer remembered threads for everyone.

Is this to mark which messages in the thread are new? If you're okay to rely on JavaScript a little more for this, it could also be put into local storage of the browser which has much larger limits and isn't sent to the server on every request.

I stopped by the drive-thru at the newest In-N-Out Burger by my house and ordered a cheeseburger and fries, both animal-style. At the pick-up window, the staffer asked if I wanted grilled onions on my animal fries, and I confusingly said "yes" (e.g., it's not animal style without the grilled onions). However, when I got home, there were no grilled onions.

Making animal fries typically involves multiple staff members: it starts with the fry person adding cheese to the fries and melting it, the griller (often a manager or assistant manager) adds grilled onions, the burger wrapper adds the spread, and lastly, the drive-thru person briefly checks to confirm everything is correct. This is standard.

Animal-style burgers: mustard on the meat, grilled onions, extra pickles, cheese, and spread.
Animal-style fries: cheese, grilled onions, and spread.

This is the first time I've seen In-N-Out Burger mess up my order out of ignorance. It happened at a new location, which tells me the staff (including the manager) don't know what animal style means.

RedEye9 wrote on Feb 7, 2024, 16:59:

fujiJuice wrote on Feb 7, 2024, 14:44:

Tom wrote on Feb 7, 2024, 14:09:

Fricken cookies, I guess that's why the first thing anyone says is to delete your cookies if you're having a problem with a site.

Cookies can easily become corrupted. Clearing out the old cookies and getting new ones is often the simplest solution.

Staunch wrote on Feb 7, 2024, 17:03:

Frans wrote on Feb 7, 2024, 15:16:
Aware of that, but given that cookie chatbear-session-1 for a frequent visitor of the news forum is maxed out around 3800 bytes, that leaves less space for all the others combined. I guess I'll lower that limit to 3600 and then we'll have to see how it goes. It just means fewer remembered threads for everyone.

Is this to mark which messages in the thread are new? If you're okay to rely on JavaScript a little more for this, it could also be put into local storage of the browser which has much larger limits and isn't sent to the server on every request.

They are used, per forum, to keep track of which threads you've visited most recently, so they aren't starred next time unless there is a new post. This was developed by original Chatbear programmer Bagpuss, and every time I look at it, my brain briefly short-circuits before relaxing again. So no, not going to rewrite into JS...

RedEye9 wrote on Feb 7, 2024, 16:59:

fujiJuice wrote on Feb 7, 2024, 14:44:
I thought I posted about it then but can't seem to find it.

here it is

Thanks. I was so young back then. I looked good.

I vote you get Frans to change that error message to...."Vger will comply when the carbon units provide the necessary information."

On Apache2 there is an option to increase the header size limit.
https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize

Nginx also has a similar option.
https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers

Grokk wrote on Feb 8, 2024, 01:21:
On Apache2 there is an option to increase the header size limit.
https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize

Yes, I already linked that in my post #5. But some warn against it as it could increase DDoS risks.