Some backround info for context..

I'm writing a simple weather forecast reader in JS which makes use of multiple
APIs for determining location data and then forecast data based on that location.

For US cities, the weather.gov API takes a specified latitude and longitude as URL parameters, and gives you a forecast URL for that area. Since the average person walking around typically doesn't have latitude and longitude coordinates commited to memory, I decided to use another API, geocode.maps.co, to return the latitude and longitude for a specified city.

I have all of this working. However whenever I make the HTTPRequest call to geocode.maps.co, SBBS logs TLS errors to error.log like this one:

term 33736 TLS ERROR 'No data was read because the remote system closed the connection (recv() == 0)' (-1) popping data

This happens on *successful* HTTPRequest calls to this API. The HTTPRequest is getting the response from the API containing the json data for the specified input, but it's logging a TLS error at the same time. The calls are placed in a try/catch block, but the catch does not get hit in this scenario.

To the user, it appears nothing is wrong whatsoever. But to me, I see TLS errors logged every time someone uses the functionality to query location data. None of the other APIs I'm using are leading to this outcome; just this one.

Which leads me to my question: is there a way I can suppress those TLS errors, or am I stuck with them cluttering the error.log file?

---
■ Synchronet ■ -=[ conchaos.synchro.net | ConstructiveChaos BBS ]=-

Re: Suppressing HTTPRequest TLS Errors
By: Codefenix to All on Fri Mar 25 2022 11:22 am

> Some backround info for context..
>
> I'm writing a simple weather forecast reader in JS which makes use of
> multiple APIs for determining location data and then forecast data based on
> that location.
>
> For US cities, the weather.gov API takes a specified latitude and longitude
> as URL parameters, and gives you a forecast URL for that area. Since the
> average person walking around typically doesn't have latitude and longitude
> coordinates commited to memory, I decided to use another API,
> geocode.maps.co, to return the latitude and longitude for a specified city.
>
> I have all of this working. However whenever I make the HTTPRequest call to
> geocode.maps.co, SBBS logs TLS errors to error.log like this one:
>
> term 33736 TLS ERROR 'No data was read because the remote system closed the
> connection (recv() == 0)' (-1) popping data
>
> This happens on *successful* HTTPRequest calls to this API. The HTTPRequest
> is getting the response from the API containing the json data for the
> specified input, but it's logging a TLS error at the same time. The calls
> are placed in a try/catch block, but the catch does not get hit in this
> scenario.

Yeah, the Socket object doesn't throw JS exceptions. It probably should (rather than directly log errors).

There's likely something that the http.js should be doing but isn't, to avoid that error. It's not something I've played with much. I'd see if you can catch deuce on irc.synchro.net #synchronet.

I could probably do the throwing-exceptions change myself, but the actual "fix" might just be a change to http.js.

> To the user, it appears nothing is wrong whatsoever. But to me, I see TLS
> errors logged every time someone uses the functionality to query location
> data. None of the other APIs I'm using are leading to this outcome; just
> this one.
>
> Which leads me to my question: is there a way I can suppress those TLS
> errors, or am I stuck with them cluttering the error.log file?

For the moment, yeah, but I'm sure there's a solution.
--
digital man (rob)

This Is Spinal Tap quote #26:
David St. Hubbins: They were still booing him when we came on stage.
Norco, CA WX: 81.9°F, 28.0% humidity, 5 mph ESE wind, 0.00 inches rain/24hrs
---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

Re: Suppressing HTTPRequest TLS Errors
By: Digital Man to Codefenix on Fri Mar 25 2022 12:31 pm

DM> For the moment, yeah, but I'm sure there's a solution.

OK, thanks for the reply. I'll live with it for now. :)

---
■ Synchronet ■ -=[ conchaos.synchro.net | ConstructiveChaos BBS ]=-