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
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.
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
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!
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