On Tue, 12 Apr 2022 16:07:07 -0700 (PDT), Randall <rsbecker@nexbridge.com> wrote:

>On Tuesday, April 12, 2022 at 10:20:07 a.m. UTC-4, JShepherd wrote:
>> In article <9c25562c-6170-4c38...@googlegroups.com>,
>> rkd...@gmail.com says...
>> >
>> >On Monday, April 11, 2022 at 12:44:10 PM UTC-7, Bill Honaker wrote:
>> >> On Mon, 11 Apr 2022 12:36:00 -0700 (PDT), Keith Dick <rkd...@gmail.com> w=
>> >rote:=20
>> >>=20
>> >> >On Monday, April 11, 2022 at 8:22:13 AM UTC-7, Bill Honaker wrote:=20
>> >> >> On Mon, 11 Apr 2022 02:29:08 -0700 (PDT), Keith Dick <rkd...@gmail.com=
>> >> wrote:=20
>> >> >>=20
>> >> >> >On Sunday, April 10, 2022 at 6:57:44 PM UTC-7, red floyd wrote:=20
>> >> >> >> On 4/10/2022 1:01 PM, Keith Dick wrote:=20
>> >> >> >> > On Sunday, April 10, 2022 at 11:48:12 AM UTC-7, Bill Honaker wrot=
>> >e:=20
>> >> >> >> >> On Sat, 9 Apr 2022 15:22:56 -0700 (PDT), Keith Dick <rkd...@gmai=
>> >l.com> wrote:=20
>> >> >> >> >>=20
>> >> >> >> >>> Is there some system or network problem that results in attempt=
>> >s to get to the library of open source packages for the NonStop system to g=
>> >et error 404? Or has ituglib been moved to some other location?=20
>> >> >> >> >>>=20
>> >> >> >> >>> I get the error 404 both when using my bookmark directly to the=
>> > page for the itug open source library and when going to connect-community.=
>> >org, searching for ituglib, and clicking on the button for ituglib in the s=
>> >earch results.=20
>> >> >> >> >> I had no problem just now. Tried with both Chrome and Edge. Just=
>> > to make sure, this is the 'official' link:=20
>> >> >> >> >>=20
>> >> >> >> >> https://ituglib.connect-community.org/apps/Ituglib=20" rel="nofollow" target="_blank">https://ituglib.connect-community.org/apps/Ituglib=20
>> >> >> >> >=20
>> >> >> >> > Thanks for the reply, Bill. That link still gives me the 404 erro=
>> >r. I've tried Chrome and Firefox on Windows 7 and a Mac. I wonder whether m=
>> >y ISP (Comcast) is blocking that address for some reason. It worked okay th=
>> >e last time I accessed it sometime early last week. Odd. Are you aware of a=
>> >ny change to the IP address and/or DNS records for ituglib.connect-communit=
>> >y.org?=20
>> >> >> >> >=20
>> >> >> >> > Maybe I'll download and install one of the other web browsers and=
>> > see whether that makes a difference. If it works for a freshly-downloaded =
>> >browser, it would not be the ISP blocking things.=20
>> >> >> >> >=20
>> >> >> >> > (Oh, Firefox on Mac did not give a 404 error -- it just displayed=
>> > an empty page. Chrome on Mac did give the 404 error. Odd that Firefox gave=
>> > no error on the Mac.)=20
>> >> >> >> Works here. FF/Win11=20
>> >> >> >=20
>> >> >> >To Randall -- The problem is not with any package in the library. The=
>> > error 404 occurs before reaching the page that lists the packages in the l=
>> >ibrary. Since it is working for other people, the problem must be close to =
>> >my end. Since it happens when accessing from two of my computers, it might =
>> >be happening in my ISP or in whatever DNS my ISP uses. If you happen to kno=
>> >w the numeric IP address for ituglib.connect-community.org, post that and I=
>> > could see whether using the numeric address instead of the DNS name allows=
>> > the page to load. If so, then the problem would be in the DNS my ISP uses.=
>> >=20
>> >> >> Keith, it's 12.238.63.163=20
>> >> >=20
>> >> >Thanks for the numeric IP address, Bill. Using the numeric IP address al=
>> >lows me to get to the open source library page, but using the DNS name does=
>> > not.=20
>> >> >=20
>> >> >After a bit more experimenting I learned a little more. The problem appe=
>> >ars to have something to do with the open source library pages not supporti=
>> >ng https connections. Apparently, the version of the Chrome browser I have =
>> >will try using http when the URL has the numeric form of the server address=
>> >, but will not try http when the URL has the DNS name form of the server ad=
>> >dress. On one of the computers, the bookmark won't include http:// in front=
>> > of the server address in what it saves for the bookmark (even if I explici=
>> >tly include http:// when editing the URL in the bookmark), but on the other=
>> > computer, the bookmark will include http:// in what it saves for the bookm=
>> >ark. So on the second computer, I've changed my bookmark for the open sourc=
>> >e library so it works again, but on the first computer I guess I'm going to=
>> > have to let clicking on the bookmark get the error 404 then manually fix t=
>> >he URL in the address bar to use http instead of https.=20
>> >> >=20
>> >> >I'm not certain that explanation is 100% correct, but that's what seems =
>> >to be happening.=20
>> >> >=20
>> >> >I used one of those computers (don't recall which one) to access the ope=
>> >n source library page last week, so something apparently changed on one of =
>> >my computers in the past week (unless the open source library pages at itug=
>> >lib just stopped working with https in the past week).=20
>> >> >=20
>> >> >Mystery mostly solved, I think.
>> >> Keith,=20
>> >>=20
>> >> Not completely solved. The URL I posted above is SSL... https://=20
>> >>=20
>> >> To support customers that needed some auithentication that there was no m=
>> >an in the middle attack, we moved to SSL years ago.=20
>> >> I do see that our certificate expires at the end of this month so I'd bet=
>> >ter get on that. :-)=20
>> >>=20
>> >> Enteriing https://12.238.63.163/apps/ituglib/," rel="nofollow" target="_blank">https://12.238.63.163/apps/ituglib/, your browser probably comp=
>> >lains because the common name in the certificate doesn't match.=20
>> >>=20
>> >> Are you using some kind of relay in your browser that may be passing the =
>> >query elsewhere?=20
>> >> Bill
>> >
>> >Bill,
>> >
>> >Using https://12.238.63.163/apps/ituglib/ gets this exact display from Chro=
>> >me (as much as this newsgroup interface can reproduce, anyway):
>> >
>> >----------------- start response ------------------------------
>> >This 12.238.63.163 page can=E2=80=99t be found
>> >No webpage was found for the web address: https://12.238.63.163/apps/itugli=
>> >b/
>> >
>> >HTTP ERROR 404
>> >------------------ end response ---------------------------------------
>> >
>> >If I change the "ituglib" in that URL to "Ituglib" (that is, capital "i"),=
>> > the page loads but Chrome puts "Not secure" in red letters in the address =
>> >bar before the URL and displays the URL with the "https" having two horizon=
>> >tal strike-out lines through it. I believe that means it switched to HTTP=
>> >, but that's just a guess on my part.
>> >
>> >I have seen Chrome error messages occasionally when a web site's certificat=
>> >e has expired, and that error message specifically mentions a problem with =
>> >the certificate, and I'm pretty sure it does not says it was a 404 error, t=
>> >hough I cannot be sure of what error number it was.=20
>> >
>> >I have a feeling that if the browser was complaining about a mismatch for a=
>> > name in the certificate, that error message also would mention the certifi=
>> >cate specifically, though I am not certain of that. Maybe I'm not getting =
>> >a complaint about the name mismatch because the browser was successful drop=
>> >ping back to HTTP, which doesn't use the certificate.
>> >
>> >Do you want me to do any more investigation of this? Or shall we just drop=
>> > it?
>>
>>
>>
>> I have used this HTTP viewer in the past to research connection issues
>>
>> An Ituglib.connect-community.org session
>> ---------------------------------------------
>> Rex Swain's HTTP Viewer
>> http://www.rexswain.com/httpview.html
>> Code last updated 21 March 2020
>> Request:
>>
>> GET https://Ituglib.connect-community.org/ HTTP/1.1
>> Host: Ituglib.connect-community.org
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0)
>> Gecko/20100101 Firefox/99.0
>> Referer: http://www.rexswain.com/httpview.html
>> Connection: Close
>>
>> Response Header:
>>
>> HTTP/1.1 302 Found
>> Connection: close
>> Date: Tue, 12 Apr 2022 14:10:35 GMT
>> Location: https://ituglib.connect-community.org/apps/Ituglib
>> Server: iTP Secure WebServer/7.5
>> Content-Type: text/html
>> MIME-Version: 1.0
>>
>> Content (Length = 245):
>> <TITLE>Redirection</TITLE><H1>Redirection</H1>(LF)
>> ·This·document·can·be·found·
>> <A·HREF="https://ituglib.connect-community.org/apps/Ituglib">elsewhere.</A>
>> (LF)
>> ·<P>You·see·this·message·because·your·browser·doesn't·support(LF)
>> ·automatic·redirection·handling.
>> Done
>>
>> Elapsed time so far: 2 seconds
>>
>> The Location: line in the header above would redirect your browser to a new
>> URL:
>> Location 2
>> Request:
>>
>> GET https://ituglib.connect-community.org/apps/Ituglib HTTP/1.1
>> Host: ituglib.connect-community.org
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0)
>> Gecko/20100101 Firefox/99.0
>> Referer: http://www.rexswain.com/httpview.html
>> Connection: Close
>>
>> Response Header:
>>
>> HTTP/1.1 302 Redirect
>> Connection: close
>> Date: Tue, 12 Apr 2022 14:10:36 GMT
>> Location: https://ituglib.connect-community.org/apps/Ituglib/
>> Server: iTP Secure WebServer/7.5
>> MIME-Version: 1.0
>>
>> Content (Length = 0):
>> Done
>>
>> Elapsed time so far: 3 seconds
>>
>> The Location: line in the header above would redirect your browser to a new
>> URL:
>> Location 3
>> Request:
>>
>> GET https://ituglib.connect-community.org/apps/Ituglib/ HTTP/1.1
>> Host: ituglib.connect-community.org
>> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0)
>> Gecko/20100101 Firefox/99.0
>> Referer: http://www.rexswain.com/httpview.html
>> Connection: Close
>>
>> Response Header:
>>
>> HTTP/1.1 200 OK
>> Connection: close
>> Date: Tue, 12 Apr 2022 14:10:37 GMT
>> Server: iTP Secure WebServer/7.5
>> Content-Type: text/html;charset=ISO-8859-1
>> MIME-Version: 1.0
>> Set-Cookie: oam.Flash.RENDERMAP.TOKEN=1208zcla1j; Path=/apps/Ituglib; Secure;
>> HttpOnly
>> Set-Cookie: JSESSIONID=$Z017$F9BC886067ABDAB0E7C1C18101B6899E;
>> Path=/apps/Ituglib;Secure; HttpOnly
>>
>> Content (Length = 13977):
>
>Because access is via an IP address, I am not sure the certificate will verify in Chrome - Bill, what do you think? The host in the URL has to be as specified in the certificate.

Randall, you're correct. Users can tell the browser to ignore but the address bar will never be clear.