400 Bad Request

Hello, since today lunch I get

https://gitlab.com/caragerman/diler-digital-learning-environment.git:
400 Bad Request

when I pull from Gitlab via Eclipse. Even when I do a fresh clone I get this error.

My colleges do not have that problem. How do I debug that? Thanks

Does your work environment require the use of proxies, or authenticated proxies? If yes, have you ensured your Eclipse settings continues to carry the necessary proxy configurations: https://wiki.eclipse.org/EGit/User_Guide?

Does the issue happen only within Eclipse, or also from the CLI? If the CLI is facing the same issue, you can attempt to troubleshoot where the 400 response is truly coming from (from GitLab or from something thatā€™s intercepting your request) by turning on some trace options, and observing each request/response: https://stackoverflow.com/a/17344517/14595652

Thank you. No I do not use or need proxies. Same happens over the CLI. This is the response using tracing but I donā€™t know what to do with that:
05:29:49.853223 git.c:439 trace: built-in: git pull origin master
05:29:49.877363 run-command.c:663 trace: run_command: git fetch --update-head-ok origin master
05:29:50.028756 git.c:439 trace: built-in: git fetch --update-head-ok origin master
05:29:50.037704 run-command.c:663 trace: run_command: GIT_DIR=.git git-remote-https origin https://gitlab.com/caragerman/diler-digital-learning-environment.git
* Couldnā€™t find host gitlab.com in the .netrc file; using defaults
* Trying 172.65.251.78:443ā€¦
* TCP_NODELAY set
* Connected to gitlab.com (172.65.251.78) port 443 (#0)
* found 385 certificates in /etc/ssl/certs
* ALPN, offering h2
* ALPN, offering http/1.1
* SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: gitlab.com (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: CN=gitlab.com
* start date: Fri, 13 Mar 2020 00:00:00 GMT
* expire date: Tue, 11 May 2021 23:59:59 GMT
* issuer: C=GB,ST=Greater Manchester,L=Salford,O=Sectigo Limited,CN=Sectigo RSA Domain Validation Secure Server CA
* ALPN, server accepted to use h2
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x560b2b0b0f00)
> GET /caragerman/diler-digital-learning-environment.git/info/refs?service=git-upload-pack HTTP/2
Host: gitlab.com
user-agent: git/2.25.1
accept: /
accept-encoding: deflate, gzip, br
accept-language: en-US, en;q=0.9, *;q=0.8
pragma: no-cache

* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 401 
< date: Thu, 19 Nov 2020 04:29:51 GMT
< content-type: text/plain; charset=utf-8
< content-length: 26
< set-cookie: __cfduid=d8974198eb69be0e45d115a60712c89691605760190; expires=Sat, 19-Dec-20 04:29:50 GMT; path=/; domain=.gitlab.com; HttpOnly; SameSite=Lax; Secure
< cache-control: no-cache
< referrer-policy: strict-origin-when-cross-origin
< www-authenticate: Basic realm="GitLab"
< x-content-type-options: nosniff
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-request-id: XpUERkfBp58
< x-runtime: 0.025197
< x-xss-protection: 1; mode=block
< strict-transport-security: max-age=15724800
< gitlab-lb: fe-03-lb-gprd
< gitlab-sv: git-gke-us-east1-b
< cf-cache-status: DYNAMIC
< cf-request-id: 06805d21940000f47e6d1fb000000001
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 5f473148effcf47e-JNB
< 
* Connection #0 to host gitlab.com left intact
Username for 'https://gitlab.com': rabeneck@digitale-lernumgebung.de
Password for 'https://rabeneck@digitale-lernumgebung.de@gitlab.com': 
* Found bundle for host gitlab.com: 0x560b2b0b7950 [can multiplex]
* Re-using existing connection! (#0) with host gitlab.com
* Connected to gitlab.com (172.65.251.78) port 443 (#0)
* Server auth using Basic with user 'rabeneck@digitale-lernumgebung.de'
* Using Stream ID: 3 (easy handle 0x560b2b0b0f00)
> GET /caragerman/diler-digital-learning-environment.git/info/refs?service=git-upload-pack HTTP/2
Host: gitlab.com
authorization: Basic cmFiZW5lY2tAZGlnaXRhbGUtbGVybnVtZ2VidW5nLmRlOm5naWdsZXJ1Ym5nbHM0NTM2X8Knc1M=
user-agent: git/2.25.1
accept: */*
accept-encoding: deflate, gzip, br
accept-language: en-US, en;q=0.9, *;q=0.8
pragma: no-cache

< HTTP/2 400 
< date: Thu, 19 Nov 2020 04:30:29 GMT
< content-type: text/plain
< content-length: 11
< set-cookie: __cfduid=d8c82d9c01d7d80bf947669baa9dcab8d1605760228; expires=Sat, 19-Dec-20 04:30:28 GMT; path=/; domain=.gitlab.com; HttpOnly; SameSite=Lax; Secure
< x-request-id: 5LjUHkCyxr6
< x-runtime: 0.000408
< strict-transport-security: max-age=15724800
< gitlab-lb: fe-05-lb-gprd
< gitlab-sv: git-gke-us-east1-d
< cf-cache-status: DYNAMIC
< cf-request-id: 06805db4450000f47e539b8000000001
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 5f473233adaaf47e-JNB
< 
* Connection #0 to host gitlab.com left intact
remote: Bad Request
fatal: unable to access 'https://gitlab.com/caragerman/diler-digital-learning-environment.git/': The requested URL returned error: 400

Thanks. I donā€™t use proxies. Same error also from the CLI. I pasted the result of the Git trace here but my post got deleted because of that. So what is the purpose of having an editor the allows you to past code only to delete the post afterwards?

I just took a laptop I had not used for half a year and I get the same error. I conclude there is something wrong in my gitlab account. Is there some sort of clean up or hard reset?

So what is the purpose of having an editor the allows you to past code only to delete the post afterwards?

I am unaware of what text pattern rules apply to such auto-deletion, Iā€™ll try to find out. Its possible that something sensitive may have been detected that lead to deletion for safety.

I conclude there is something wrong in my gitlab account. Is there some sort of clean up or hard reset?

Do you have 2-Factor Authentication (2FA) active on your account? If yes, is your passed personal token for authentication in Git CLI/Plugins still active/unexpired? You can try to regenerate one if it has passed a previously-set expiration date.

Are you able to login to GitLab.com Web UI with your account credentials, without any issues?

Edit: If it does, and youā€™re using a credential-inclusive URL such as https://user:pass@domain/path/project.git then please retry supplying the password in percentage encoding, using git remote set-url.

Thanks again. I figured that last night something changed in Gitlab. My special chars containing password no longer works when pulling. So I took these out and all is good.

I can confirm this.
I had the exact same problem (internal Gitlab support request #181002, will close now) and my Gitlab password contained an Ƥ.

After changing the password, everything is working again.

I have the same problem and solution too. I hope the problem gets fixed, though, to not bug out on passwords with special characters.

Same here. Cannot push via HTTPS. Login on the webpage works as expected though. Changed my password from containing Unicode special characters to only containing ASCII special characters (only from the first 128) and I could push via HTTPS again.

As unicode passwords provide higher entropy I hope someone at Gitlab will take a look at this. Iā€™d also be willing to share my old password with staff (it was unique to Gitlab and is now no longer in use) if that speeds up fixing the issue.

Same here, after migrating from 13.5.2 to 13.6.0, one user with german umlaut in his password couldnā€™t use the api anymore. Login via browser worked flawless, but using any git cli command failed with 400 Bad Request

1 Like

Thank you so much for finding the solution to this. Same as above, had an ā€˜Ć¤ā€™ in the password and got error 400

After hours of reinstallations and trying out various tools, this thread provided me with the solution. My password as well contained the ā€˜Ć¤ā€™ character. Thank you!

does the newest version 13.6.2 have fixed this problem?

My colleagues and myself experienced this problem yesterday after updating to 13.6.2,
Norwegian character ā€˜Ć„ā€™ was the culprit, and the only moving part (to my knowledge) was the Gitlab update.

As for @Bytecruncher, 13.5.2 did not produce this problem for us.

The 400 (Bad Request) status code indicates that the server cannot or will not process the request because the received syntax is invalid, nonsensical, or exceeds some limitation on what the server is willing to process. It means that the request itself has somehow incorrect or corrupted and the server couldnā€™t understand it. The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method . Therefore, it prevents the website from being properly displayed. The main thing to understand is that the 400 Bad Request error is a client-side error.

The cause of 400 Bad Request error can be a wrongly written URL or a URL that contains unrecognizable characters. Another cause of the error might be an invalid or expired cookie. Also, if you try to upload a file thatā€™s too large. If the server is programmed with a file size limit, then you might encounter a 400 error.

Expired Client Certificate

This issue typically happens for a 2-Way TLS, when the certificate sent by the client is expired. In a 2-way TLS, both client and server exchange their public certificates to accomplish the handshake. The client validates the server certificate and the server validates the client certificate. During the TLS handshake if it is found that the client certificate is expired, then the server will send 400 - Bad request with the message ā€œThe SSL certificate errorā€. The solution for this problem is that procure a new certificate and upload the certificate