After some experimentation, I managed to get a URL similar to the one you show (starting with "?response_type=..."), which isn't a valid URL. It should look more like this (i.e. starting with "https://...") ...
.

I'm not sure yet why the bad URL response isn't accompanied by a status code; apparently the back end is taking a "you asked for it, you got it" approach.

In my case, I was playing with the GMAIL authentication and the OAUTH2.BP sample program. The issue (for me) came down to the fact that my client credentials did not include the necessary name:value pairs that the sample program was looking to extract from the json file. (The issue was that the Google API console had changed the names used in their json file.) But ultimately it's a matter of making sure you actually have values for all of the OAUTH2 parameters required for that API (client id, secret, port, authorization endpoint, token endpoint, challenge and scope).

That's probably not enough to solve your issue, but hopefully helps you focus on adjusting those parameters until you get a URL response that looks like an actual URL. But if that's not getting you anywhere, feel free to send me the details needed so I can try to access the API from here.

Oh well. I thought maybe I was in line for a kickback, or perhaps some kind of bidirectional pop-up ad promotion? (It's easy to imagine A-Shell developers starting at our HH topic in the AshRef and clicking on the HH Madeira pop-up ad; it might be a bit more challenging to lure wine shoppers over to XTREE. But they'll be glad they did!)

Here's a beta release of the update that fixes this problem:

ash-7.0.1757.5-el7-upd.tz
ash70notes.txt

And although it's not related to the compiler issue and not specific to this version, this update of the ashnet library is recommended:

libashnet.so.1.14.194-el7.tz

For what it's worth, along with the fix for the ++IFDEF <structname> issue (discussed here), I've added the following stats to the end of the LSX file in the hopes of perhaps making it easier to identify compiler performance issues, or at least quantify them. (This is from your prccstdsp program compiled under Windows) ...

As the asterisked note indicates, unfortunately, measuring the time used in routines that take almost no time per call, but which get called tens of thousands of times, potentially adding up to real time, is not very reliable when the time for a single call isn't significantly longer than the clock resolution. The Windows CPU clocks use 100-nanosecond units, but it's not clear whether the actual resolution is that fine, or whether, for example, each search for a structure name in the structure definition index takes significantly less than that, thus making it look like the 15041 searches took no time at all. Also, the total CPU time for the 4 search routines itemized is very close to the total CPU time for the entire compilation, which is ridiculous, because there's a lot of other code in the compilation that wasn't being separately itemized. So that strongly implies that whether or not a routine gets properly measured is a bit like Russian Roulette (either it gets off for free because the clock didn't change, or it gets hit with a big charge, most of which should have gone against prior routines.

Another detail which stands out is that the initial pre-scan (Phase 0) actually took longer than the main compilation (Phase 1), which surprised me. Partly that may be because the pre-scan had to look at 3 times as many routines as the main scan. And partly it may be because the pre-scan is having to build these various index trees, offloading some of the work from the main scan (which mostly then was doing a lot of searches of those trees). Or maybe there is some inefficiency there which needs to be squeezed out. But here we can't blame the clock resolution because it's measuring once at the start and once at the end of each phase (which are plenty long enough to make the clock resolution a non issue).

Another surprising result is that the total elapsed time is so much more than the CPU time. That suggests that the OS devoted almost 2/3 of its time to other background processes. (Not entirely out of the question, especially with Windows, but still a bit surprising.)

Anyway, I'll probably post the update later tonight or tomorrow, but now that you have your workaround, and considering how apparently rare it is for the original problem to actually be triggered, it's not clear there's any urgency.

OK, that is great. Thank you Jack

I found another FTP2 bug related to the XFTPF_RENAME, XFTPF_DEL and XFTPF_RMVEXT opcodes; the fix is in 1757.4 ...

ash-7.0.1757.4-el7-upd.tz
ash70notes.txt

Thanks for the headsup!