magit/ghub

400 Bad Request with Gitlab

webframp opened this issue · 8 comments

webframp commented

Just checking if this is an error in my setup, an outdated Gitlab instance or an actual issue. It seems to occur infrequently, perhaps due to some builtin api throttling on Gitlab?

For some repos hosted on a private Gitlab instance I get this error when I run forge-pull:

error in process filter: HTTP Error: 400, "Bad Request", "/api/v4/projects/2366/merge_requests/19/notes?per_page=100", ((message . "<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor=\"white\">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>") (documentation_url . "https://github.com/magit/ghub/wiki/Github-Errors"))

Many time retrying after 15-20 minutes will succeed.

This is a Gitlab 11 instance. Other repositories work fine so I'm not sure how best to debug this or provide a more useful report. The most recent one with an issue is relatively small with only 19 MRs and a short 7 month git history. One that recently worked just fine had 140+ MRs and much longer history.

tarsius commented

ghub always uses https. That is hard-coded in the ghub-request function. So my guess is that this is a Gitlab bug.

npostavs commented

Or possibly the libgnutls thing if @webframp is using Emacs 26.2 or earlier. Though it was previously reported as just missing headers, that bug typically causes the "bad request" symptom when contacting GNU ELPA.

webframp commented

Version info with build flags if it helps. Currently installed version of gnutls is 3.6.9.

((emacs
  (version . "26.3")
  (features . "JPEG RSVG IMAGEMAGICK GLIB NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS LCMS2")
  (build . "Aug 30, 2019")
  (buildopts "--disable-dependency-tracking --disable-silent-rules --enable-locallisppath=/usr/local/share/emacs/site-lisp --infodir=/usr/local/Cellar/emacs-plus/26.3/share/info/emacs --prefix=/usr/local/Cellar/emacs-plus/26.3 --with-xml2 --without-dbus --with-gnutls --with-imagemagick --with-modules --with-rsvg --with-ns --disable-ns-self-contained")
  (windowsys . batch)
  (daemonp . server-running))
  (system
  (type . darwin)
  (config . "x86_64-apple-darwin18.7.0")
  (shell . "/usr/local/bin/zsh")
  (uname . "Darwin 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64")
  (path "/usr/local/sbin" "/usr/local/bin" "~/.local/bin" "~/.cargo/bin" "~/.krew/bin" "~/bin" "~/go/bin" "/usr/local/sbin" "/usr/local/bin" "/usr/bin" "/bin" "/usr/sbin" "/sbin" "/usr/local/Cellar/emacs-plus/26.3/libexec/emacs/26.3/x86_64-apple-darwin18.7.0")))
npostavs commented 
  (version . "26.3")

Okay, not Emacs Bug#34341 then,

 (config . "x86_64-apple-darwin18.7.0")

but it might be Bug#36017 which is macOS specific. Does (setq ghub-use-workaround-for-emacs-bug 'force) help?

webframp commented

Tried again with the workaround setting, here's the result. This is the error from the messages bugger again without the setting (interesting that it shows twice?):

error in process filter: ghub--signal-error: HTTP Error: 400, "Bad Request", "/api/v4/projects/2393/merge_requests/135/notes?per_page=100", ((message . "<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor=\"white\">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>") (documentation_url . "https://github.com/magit/ghub/wiki/Github-Errors"))
error in process filter: HTTP Error: 400, "Bad Request", "/api/v4/projects/2393/merge_requests/135/notes?per_page=100", ((message . "<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor=\"white\">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>") (documentation_url . "https://github.com/magit/ghub/wiki/Github-Errors"))

Then I eval'd (setq ghub-use-workaround-for-emacs-bug 'force) to apply the setting. There is still an error but it's different and possibly more useful (again, occurs twice) ?

error in process sentinel: ghub--handle-response-headers: BUG: missing headers
  See https://github.com/magit/ghub/issues/81.
  headers: nil
  status: (:error (error connection-failed "connect" :host "gitlab.selfhosted.url" :service 443))
  buffer: #<buffer  *http gitlab.selfhosted.url:443*-327752>
error in process sentinel: BUG: missing headers
  See https://github.com/magit/ghub/issues/81.
  headers: nil
  status: (:error (error connection-failed "connect" :host "gitlab.selfhosted.url" :service 443))
  buffer: #<buffer  *http gitlab.selfhosted.url:443*-327752>

I'm interested to debug this a little more, so let me know how best to do that as needed.

webframp commented

Have been running for a little while, with (setq ghub-use-workaround-for-emacs-bug 'force) set. It does seem to help, I still get the issue at times but it seems like I can retry and it will often succeed now.

This is shown from the messages buffer, first attempt to do forge-pull failed with 400s, second attempt worked fine.

<body bgcolor=\"white\">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>") (documentation_url . "https://github.com/magit/ghub/wiki/Github-Errors"))
error in process filter: HTTP Error: 400, "Bad Request", "/api/v4/projects/o11n%2Ffearlessly", ((message . "<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor=\"white\">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>") (documentation_url . "https://github.com/magit/ghub/wiki/Github-Errors"))
Quit [2 times]
Pulling o11n/fearlessly...
Pulling o11n/fearlessly issues...done
Pulling o11n/fearlessly pullreqs...done
Pulling o11n/fearlessly...done
Storing o11n/fearlessly...done
Running git fetch origin
Git finished
tarsius commented

Does (setq ghub-use-workaround-for-emacs-bug 'force) help?

That should not be necessary anymore as its the default for macOS now. See #81.

It does seem to help, I still get the issue at times but it seems like I can retry and it will often succeed now.

I don't know what else to do. It seems Emacs' network stack just isn't very good...
I am closing this for now, but if there's new information I would be happy to take another look.

jjparkSuperman78 commented

i have a same problem. any other solutions here ?