Package: emacs;
Reported by: "tenspd137 ." <dcday137 <at> gmail.com>
Date: Tue, 28 May 2019 22:26:02 UTC
Severity: normal
Found in version 26.2
Done: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
Bug is archived. No further changes may be made.
Message #43 received at 35969 <at> debbugs.gnu.org (full text, mbox):
From: "tenspd137 ." <dcday137 <at> gmail.com> To: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>, 35969 <at> debbugs.gnu.org Subject: Re: bug#35969: 26.2, Excorporate Date: Fri, 14 Jun 2019 14:16:05 -0600
*if I try to C-x C-e or M-: "connection", it goes into the debugger.*
I mean it gives me a backtrace telling me the variable is empty, even
though later in lisp expressions, it is evaluated. I am assuming it
is roughly equivalent to a C++ pointer, but I don't know how to query
it, etc.
Thanks!
-C
On Fri, Jun 14, 2019 at 2:13 PM tenspd137 . <dcday137 <at> gmail.com> wrote:
>
> Thomas -
>
> I was able to try stepping through an Emacs/proxy/Exchange test in an
> emacs -Q session. After setting the proxy and configuring the
> debugger to step through url-http and url-http-async-sentilnel, the
> only thing I noticed is that it appears url-http-async-sentinel is not
> being called. I also put the url-https-proxy-connect override you
> gave me earlier into a file, loaded it and set the debugger to run
> through that as well as set up proxies. A broken down list of steps:
>
> 1. Load file containing proxy and altered url-https-proxyconnect, set
> debugger to run through it when hit.
> 2. set up url-http and url-http-async-sentinel to be picked up by debugger
> 3. eval (url-retrieve-synchronously
> "https://outlook.office365.com/EWS/Exchange.asmx"), step through
> url-http
> 4. Input username and password when asked
> 5. Continue stepping until end
>
> url-http-async-sentinel is never called. " *http* ... -####" has text
> indicating failure. url-https-proxy-connect is indeed called. I don't
> know how to look at the actual <process>, if I try to C-x C-e or M-:
> "connection", it goes into the debugger. The url's, etc look good as
> far as I can tell. Not sure what else I can do. If there are certain
> pieces of url-http you want me to look at, just let me know, but not
> really knowing what has to happen under the hood, I am not going to be
> able to do much else.
>
> Thanks!
>
> -C
>
>
>
> On Tue, Jun 4, 2019 at 4:28 PM Thomas Fitzsimmons <fitzsim <at> fitzsim.org> wrote:
> >
> > "tenspd137 ." <dcday137 <at> gmail.com> writes:
> >
> > > Oh - I see. Because you want to look at the *HEADERS* flying around
> > > in that case. Understood.
> >
> > Right.
> >
> > > Quick question - using emacs -Q on my proxied machine
> > >
> > > (setq url-http-proxy "myproxy") doesn't seem to work, so I have been just doing:
> > >
> > > (setq url-proxy-services '(("http" . "myproxy")
> > > ("https" . "myproxy")))
> > >
> > > then, I evaluate:
> > >
> > > (defun url-https-proxy-connect (connection)
> > > (setq url-http-after-change-function 'url-https-proxy-after-change-function)
> > > (message "THIS WAS CALLED: url-https-proxy-connect")
> > > (process-send-string connection (format (concat "CONNECT %s:%d HTTP/1.1\r\n"
> > > "Host: %s\r\n"
> > > "\r\n")
> > > (url-host url-current-object)
> > > (or (url-port url-current-object)
> > > url-https-default-port)
> > > (url-host url-current-object))))
> > >
> > > which, if I understand correctly, adds the messaging to the orgiinal
> > > url-https-proxy-connect.
> >
> > That's correct.
> >
> > > Then I evaluate
> > >
> > > (url-retrieve-synchronously "https://outlook.office365.com/EWS/Exchange.asmx")
> > >
> > > after sending username and password, THIS WAS CALLED does not appear
> > > in the messages. Am I using it correctly, or is this not being
> > > called? I have to ask, because at this point in my emacs usage, I
> > > always bet first that I have done something wrong.
> >
> > I think you're doing everything correctly, so this suggests that Emacs
> > isn't doing any proxy handling, or at least that it is not initiating
> > the "CONNECT" protocol.
> >
> > From the wget output in your other email, it shows wget
> > connecting to the proxy with CONNECT. This protocol keeps the TLS
> > "tunnel" through the proxy open, and as far as I know, is required for
> > Exchange authentication to work through a proxy.
> >
> > Then the logs also show:
> >
> > Connection: Keep-Alive
> > Proxy-Connection: Keep-Alive
> >
> > which are important; even when you set Connection keep-alive, Emacs was
> > still sending both Connection close and Connection keep-alive which is
> > probably not valid.
> >
> > You may have reached the limit of what Emacs can currently do for
> > proxies, but it's up to someone (maybe me) to eventually implement
> > CONNECT properly if it isn't already.
> >
> > A next step would be to repeat your Emacs/proxy/Exchange experiments
> > until you get url-https-proxy-connect to be called or figure out why it
> > isn't being called.
> >
> > The only two callers are url-http and url-http-async-sentinel. To step
> > through them with edebug do:
> >
> > C-h f url-http RET C-x o TAB RET C-u C-M-x
> >
> > Likewise for url-http-async-sentinel, then redo your experiment and step
> > through the functions with SPC and eval stuff with C-x e to see where
> > they go off the rails before calling url-https-proxy-connect.
> >
> > > Still looking into wget verbosity....
> >
> > I saw the other email, nice; is that output just with the -d option?
> >
> > BTW, it seems like Emacs is supposed to read the _proxy environment
> > variables the way wget does. Have you tried running emacs -Q in an
> > environment that has http_proxy and https_proxy set, and then not
> > setting any of the Emacs proxy variables and doing the Exchange
> > authentication experiment?
> >
> > Thanks,
> > Thomas
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.