400 Bad Request Error [Tracking]


#1

There have been a few reports of CloudFlare combined with our free hosting causing 400 Bad Request Errors on certain browsers.

I can replicate this issue currently only on Google Chrome / Canary, when I turn ON “Do Not Track” this causes the bad request error (most likely the cookie/header is too large)

The login/form works fine and I can proceed like normal.

If you are affected by this issue PLEASE REPLY TO THIS THREAD!

  1. Your 000webhostAPP URL where the issue occurs
  2. Browsers you’ve experienced the error on
  3. Operating Systems you’ve experienced the error on
  4. Have you got CloudFlare enabled Y/N
  5. Does disabling DO NOT TRACK on your browser resolve the error Y/N

Sites currently reported to developer


#2

Hello

I’ve got the same problem with my website https://informatykgorlice.tk

Error message:

Bad Request

Your browser sent a request that this server could not understand.
The number of request header fields exceeds this server’s limit.

Help is welcome :slight_smile:

I have this error only when i try login by https://informatykgorlice.tk/wp-login.php


#3

Any news from 000webhost developers on this topic? I’ve got the same, but testing with a basic form, I get the same issue, so it’s definitely a compatibility thing between CloudFlare and 000webhost. As it’s unique to 000webhost they clear need to change something.

No forms work at all on my sites, which prevents logins, and searching while connected to CloudFlare.

Would be good to hear that someone at 000webhost was reviewing change logs, talking with CloudFlare and generally focused on this, as it’s a big issue.

Jay


#4

After a bit of Googling the suggestion for Chrome users or Canary or other browsers facing this issue is to turn off “Do Not Track”


#5

https://support.google.com/chrome/answer/2790761


#6

For clarity, I assume 000webhost will look to fix this, rather than ask us to tell our customers to change their browser settings.

If it helps, I’ve moved one of my sites onto another hosting provider and run a super simple form. It failed on 000webhost, but works on the other provider. The headers returned while on the other provider (via CloudFlare) were as below. I’ve removed my domain name to avoid advertising :slight_smile:

Host: [my domain - no http, just www and onwards]
X-Forwarded-Proto: https
X-Real-IP: 162.158.90.21
X-Forwarded-For: 2a02:c7d:59ab:a700:a902:415a:bf97:2895, 162.158.90.21
Connection: close
Content-Length: 38
Accept-Encoding: gzip
CF-IPCountry: GB
CF-RAY: 4a3d0455cbe2befd-FRA
CF-Visitor: {"scheme":"https"}
cache-control: max-age=0
origin: [my domain name - https version]
upgrade-insecure-requests: 1
content-type: application/x-www-form-urlencoded
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) snap Chromium/71.0.3578.98 Chrome/71.0.3578.98 Safari/537.36
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
referer: [test form url - https version]
accept-language: en-US,en;q=0.9
dnt: 1
cookie: __cfduid=d3a23d138dead90ef84581600b72081481548928985; _ga=GA1.3.1160296321.1548928986; __test=6e638c88be70214bd4c7bebfd605faea; PHPSESSID=d700804e8dc60acfc7c78fd090be0284; _gid=GA1.3.1758994032.1549235188
CF-Connecting-IP: 2a02:c7d:59ab:a700:a902:415a:bf97:2895
CDN-Loop: cloudflare

#7

Hi @Infinity, any more news from the 000webhost devs on this issue?.. I’ve been following on the forums hoping for an update, but now I’m getting more and more users reporting this problem.

Thanks.


#8

I’ve reported the few cases I’ve known about and they’ve replied disabling do not track solves for now, the more people who have this error if they could post up it’d be great to relay this to developers


#9

Thanks @Infinity. Based on my simple form, I assume this must impact everyone with an html form on their site, which surely is most people? Telling us to tell all our site visitors to change their browser settings is mad!

That said, I’ve just tried enabling the ‘Send a “Do Not Track” request with your browsing traffic’ in my Chromium… even clearing the cache afterwards, it didn’t fix the issue for me.

As @Infinity says, please can others post to confirm if they have this issue too? It will really help get some focus on this


#10

Well add me to the list, however it has only been reported to me on Chrome for Android. All on Oreo. My login page loads fine, but landing page after login receives the Bad Request.

^This!.. Mad, and simply not possible or professional.

Look forward to a solution from you guys ASAP, as this is isolated only to 000webhost from what I have been able to find.

Edit: Checked with one user. “Don’t Track” does NOT solve the problem, even when clearing cache and cookies…


#11

The ticket is still open with developers please all affected post your site URL and describe when the scenario happens like when submitting a post request or logging into a script etc


#12

@Infinity, talentscout.cf/NRL/login is the dodgy page on my site, and some Chrome users have problems when POSTing with a submit button from the modal login form.

Thanks for the follow up.


#13

Thanks I’ve added it to the ticket for a developer to check on.


#14

Is there still no update on this @Infinity?

I’ve had more users reporting this problem to me in the last few days…


#15

I added a site to the list on the 23rd and 4 hours ago developer replied saying they are still busy with it and other things


#16

Thanks again for the reply @Infinity, I’ve been trying to get to the bottom of it again myself but without knowing too much about the 000webhost server setup its hard…

As far as I can tell, the default number of allowable header fields should far exceed what I’m using… I started with 19 this morning, and now I’ve edited my site to get it down to 12, and yet I’m still getting the same error message of exceeding the number… This was by combining my include resources and also disabling some features of CloudFlare that required a request header.

Perhaps the error wording is misleading, and we’re looking in the wrong place as I highly doubt 12 request headers are exceeding any limit…

EDIT: Confirmed, also only 12 request headers when direct to mysite.000webhostapp.com… and yet fully accessible by the affected browser.


#17

@Infinity, can you please specify the number of request header fields allowable on the free plan? Also, any length limits imposed on your servers.

NOTE: Disregard my debugging notes in my previous post, as I had misread… I was minimizing request headers, not the number of fields contained within one header…

I feel that I am making progress on getting to the bottom of this issue, and I am now leaning to the cause being the limitation you guys (000webhost) have put on your free plans discussed here:

The relevant Apache setting here is the LimitRequestFields Directive defined as:

Description: Limits the number of HTTP request header fields that will be accepted from the client
Syntax: LimitRequestFields number
Default: LimitRequestFields 100
Context: server config, virtual host
Status: Core
Module: core

The default Maximum number of fields has obviously been significantly reduced from 100 for the free plans as alluded to in the linked post, resulting in my ~15 fields teetering on the edge of allowable. If this can be confirmed by admin or a dev I’m willing to move on, and mark this as closed.

Thanks again for looking into this.


#18

28 Feb 07:06am GMT

Developer replied:

Finally got some good news! This got already fixed on our end, and clients will stop having any issues either today or tomorrow :slight_smile:

So give it a day maybe?
I’ve linked your latest reply to them just in case.

Pass on current limits currently but I can ask.


#19

Strugling to get that right with my website edurga.000webhostapp.com which does not succeed login when accessed diredtly and when visited through Cloudflare gives Bad Request 400 error


#20

Thanks for the update @Infinity!

I have spoken to 3 users that had the error previously, and 2 of them have had the issue resolved which is great news. It would be good to iron out the problem fully, so can you confirm it was the LimitRequestFields directive on your servers causing the issues? Can you please tell me what this has been set to now for the Free plan?

Thanks again.