bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Thomas Hisch-2

When I try to connect to our local gerrit server (https, using a custom
CAcert) every second request fails: (400 bad request error)
When I perform the test in emacs 26.1 (installed via the fedora package
manager) all request are successfull.

This is the script I'm using for my tests:

(require 'auth-source)
(require 'json)
(require 'url)
(require 'url-http)
(require 'url-vars)
(require 'subr-x)


(defcustom ims-gerrit-host "gerrit.ims.co.at"
   "hostname of the gerrit instance"
   :group 'ims-jira
   :type 'string)

(defun ims-gerrit-authentication ()
   "Return an encoded string with jira username and password."
   (let ((pass-entry (auth-source-user-and-password ims-gerrit-host)))

     (if-let ((username (nth 0 pass-entry))
              (password (nth 1 pass-entry)))
         (base64-encode-string
          (concat username ":" password)))))

(defun ims-gerrit--get-auth-headers ()
   "Helper function to setup auth header for gerrit url call."
   `(("Content-Type" . "application/x-www-form-urlencoded")
     ("Authorization" .
      ,(concat
        "Basic "
        (ims-gerrit-authentication)))))

(defun ims-gerrit--retrieve-page-as-json (path)
   "Shortcut for gerrit api PATH to return valid json."
   (let ((url-request-extra-headers (ims-gerrit--get-auth-headers)))
     (with-current-buffer (url-retrieve-synchronously
                           (concat "https://" ims-gerrit-host path))
       (goto-char (point-min))
       (re-search-forward "^$")
       (delete-region (point) (point-min))

       ;; FIXME
       (buffer-string))
       ;; (json-read-from-string (buffer-string)))
))


(defun gerrit-get-server-version ()
   (interactive)
   (switch-to-buffer "*gerritests*")
   (erase-buffer)
   (insert (emacs-version))
   (insert ?\n)
   (dolist (loopvar `(0 1 2 3 4 5 6 7 8))
     (insert (format "\n##### %d\n" loopvar))
     (insert (prin1-to-string (ims-gerrit--retrieve-page-as-json
                               "/config/server/version")))))

The emacs 27.0 build, where the test fails,  was build be me locally.
Could it be that something between emacs 26.1 and the HEAD of master
broke sth?

This is the ouput I get in emcas 27.0 (as you can see every 2nd request
is empty)

GNU Emacs 27.0.50 (build 99, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
  of 2019-03-14

##### 0
""
##### 1
"
)]}'
\"2.16.2\"
"
##### 2
""
##### 3
"
)]}'
\"2.16.2\"
"
##### 4
""
##### 5
"
)]}'
\"2.16.2\"
"
##### 6
""
##### 7
"
)]}'
\"2.16.2\"
"
##### 8
""

Regards
Thomas


In GNU Emacs 27.0.50 (build 99, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
  of 2019-03-14 built on PC-16609.ims.co.at
Repository revision: 020e69d992c98fd852e835c9bd707a8d137090f2
Repository branch: master
Windowing system distributor 'Fedora Project', version 11.0.12003000
System Description: Fedora 29 (Workstation Edition)

Recent messages:
Mark set
Quit
Saving file
/home/thomas.hisch/gitrepos/dotfiles/emacs.d/user-lisp/gerrit-urltest.el...
Wrote
/home/thomas.hisch/gitrepos/dotfiles/emacs.d/user-lisp/gerrit-urltest.el
You can run the command ‘eval-buffer’ with M-x ev-b RET
Contacting host: gerrit.ims.co.at:443
completing-read-default: Command attempted to use minibuffer while in
minibuffer
Quit
Making completion list... [2 times]
Scanning for dabbrevs...done

Configured using:
  'configure --prefix=/opt/emacs --with-x-toolkit=gtk3 --with-xpm
  --without-jpeg --without-gif --without-tiff'

Configured features:
XPM PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS PDUMPER LCMS2 GMP

Important settings:
   value of $LC_CTYPE: en_US.UTF-8
   value of $LANG: en_US.UTF-8
   locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr dabbrev emacsbug message dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs mm-decode mm-bodies mm-encode mailabbrev gmm-utils
mailheader sendmail mail-utils gnutls network-stream url-cache url-http
url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm rmc puny url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
url-vars mailcap auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib time-date vc-git diff-mode
easymenu easy-mmode elec-pair mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 65737 7435)
  (symbols 48 7667 1)
  (strings 32 23669 1937)
  (string-bytes 1 709583)
  (vectors 16 12492)
  (vector-slots 8 153584 13038)
  (floats 8 25 80)
  (intervals 56 379 0)
  (buffers 992 32))
---------------------------------------------------------------------


Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly prohibited

IMS Nanofabrication GmbH
FN: 208021 p, FB-Gericht: Wien;
Sitz: Schreygasse 3, 1020, Vienna (Austria),Tel. +43 1 214 48 94;
E-Mail: [hidden email]; DVR-Nr: 0374369; www.ims.co.at




Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Eli Zaretskii
> From: Thomas Hisch <[hidden email]>
> Date: Thu, 14 Mar 2019 12:01:54 +0100
>
> The emacs 27.0 build, where the test fails,  was build be me locally.
> Could it be that something between emacs 26.1 and the HEAD of master
> broke sth?

Please see if it weren't my recent changes in commit 9486d87cfe that
broke this.

If my changes are not the reason, I'd appreciate if you could bisect
to find the commit which broke this, since the reproduction recipe you
provided is quite complex.  Alternatively, a simpler reproducer
starting from "emacs -Q" would be welcome.

Thanks.



Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Thomas Hisch-2
On 3/14/19 1:38 PM, Eli Zaretskii wrote:
>> From: Thomas Hisch <[hidden email]>
>> Date: Thu, 14 Mar 2019 12:01:54 +0100
>>
>> The emacs 27.0 build, where the test fails,  was build be me locally.
>> Could it be that something between emacs 26.1 and the HEAD of master
>> broke sth?
>
> Please see if it weren't my recent changes in commit 9486d87cfe that
> broke this.

Thx for the fast answer.

Your  commit 9486d did not break this issue.

The commit that broke it is

84613dae5c34ea742dd9a3e56f5acb55f604b483

Reverting it locally fixed the issue for me.

Sry that that recipe was a bit too long.
Do you still want me to shrink the recipe?

Regards
Thomas

>
> If my changes are not the reason, I'd appreciate if you could bisect
> to find the commit which broke this, since the reproduction recipe you
> provided is quite complex.  Alternatively, a simpler reproducer
> starting from "emacs -Q" would be welcome.
>
> Thanks.
>
---------------------------------------------------------------------


Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail
in error) please notify the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material
in this e-mail is strictly prohibited

IMS Nanofabrication GmbH
FN: 208021 p, FB-Gericht: Wien;
Sitz: Schreygasse 3, 1020, Vienna (Austria),Tel. +43 1 214 48 94;
E-Mail: [hidden email]; DVR-Nr: 0374369; www.ims.co.at




Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Eli Zaretskii
> CC: <[hidden email]>
> From: Thomas Hisch <[hidden email]>
> Date: Thu, 14 Mar 2019 17:48:24 +0100
>
> The commit that broke it is
>
> 84613dae5c34ea742dd9a3e56f5acb55f604b483
>
> Reverting it locally fixed the issue for me.

Thanks.  Andreas, could you please take a look at this?

> Do you still want me to shrink the recipe?

No, since you've identified the change which broke this, I see no
need.  But maybe Andreas will have some questions for you.



Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Andreas Schwab
On Mär 14 2019, Eli Zaretskii <[hidden email]> wrote:

>> CC: <[hidden email]>
>> From: Thomas Hisch <[hidden email]>
>> Date: Thu, 14 Mar 2019 17:48:24 +0100
>>
>> The commit that broke it is
>>
>> 84613dae5c34ea742dd9a3e56f5acb55f604b483
>>
>> Reverting it locally fixed the issue for me.
>
> Thanks.  Andreas, could you please take a look at this?

I'm not allowed to read his mails.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Thomas Hisch-2
On 3/18/19 10:43 PM, Andreas Schwab wrote:

> On Mär 14 2019, Eli Zaretskii <[hidden email]> wrote:
>
>>> CC: <[hidden email]>
>>> From: Thomas Hisch <[hidden email]>
>>> Date: Thu, 14 Mar 2019 17:48:24 +0100
>>>
>>> The commit that broke it is
>>>
>>> 84613dae5c34ea742dd9a3e56f5acb55f604b483
>>>
>>> Reverting it locally fixed the issue for me.
>>
>> Thanks.  Andreas, could you please take a look at this?
>
> I'm not allowed to read his mails.

Do you mean mine?
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-03/msg00404.html)

My company surprisingly switched to official (= non self-signed)
certificates last week. I've tested my testcode today again with the
latest HEAD of the master branch and I can no longer reproduce this issue.

I have no idea why the old self-signed certificates caused an issue that
is fixed by reverting 84613dae5c34ea742dd9a3e56f5acb55f604b483.

Regards
Thomas



Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Eli Zaretskii
> Cc: [hidden email]
> From: Thomas Hisch <[hidden email]>
> Date: Fri, 22 Mar 2019 21:13:32 +0100
>
> My company surprisingly switched to official (= non self-signed)
> certificates last week. I've tested my testcode today again with the
> latest HEAD of the master branch and I can no longer reproduce this issue.
>
> I have no idea why the old self-signed certificates caused an issue that
> is fixed by reverting 84613dae5c34ea742dd9a3e56f5acb55f604b483.

So you are saying that we should close this bug report?



Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Thomas Hisch-2
On 3/22/19 10:00 PM, Eli Zaretskii wrote:

>> Cc: [hidden email]
>> From: Thomas Hisch <[hidden email]>
>> Date: Fri, 22 Mar 2019 21:13:32 +0100
>>
>> My company surprisingly switched to official (= non self-signed)
>> certificates last week. I've tested my testcode today again with the
>> latest HEAD of the master branch and I can no longer reproduce this issue.
>>
>> I have no idea why the old self-signed certificates caused an issue that
>> is fixed by reverting 84613dae5c34ea742dd9a3e56f5acb55f604b483.
>
> So you are saying that we should close this bug report?
>
Yes, IMO you can close it.



Reply | Threaded
Open this post in threaded view
|

bug#34855: 27.0.50; url-retrieve-synchronously Bad request Error every 2nd call

Eli Zaretskii
> Cc: [hidden email], [hidden email]
> From: Thomas Hisch <[hidden email]>
> Date: Fri, 22 Mar 2019 23:42:35 +0100
>
> On 3/22/19 10:00 PM, Eli Zaretskii wrote:
> >> Cc: [hidden email]
> >> From: Thomas Hisch <[hidden email]>
> >> Date: Fri, 22 Mar 2019 21:13:32 +0100
> >>
> >> My company surprisingly switched to official (= non self-signed)
> >> certificates last week. I've tested my testcode today again with the
> >> latest HEAD of the master branch and I can no longer reproduce this issue.
> >>
> >> I have no idea why the old self-signed certificates caused an issue that
> >> is fixed by reverting 84613dae5c34ea742dd9a3e56f5acb55f604b483.
> >
> > So you are saying that we should close this bug report?
> >
> Yes, IMO you can close it.

Thanks, done.