Troubles connecting to MMS SDC via IDLnetURL

[ericthewizard]

After digging into another help request, it looks like #60 is an actual bug, and it seems like there's trouble accessing the SITL endpoint (the public endpoint is fine). I'm able to reproduce the issue, but still no idea what's going on

[ericthewizard]

Update: found a simple test case that reproduces the issue; it looks like IDLnetURL is having trouble connecting to lasp.colorado.edu:

dummy_obj = obj_new('IDLnetURL', url_host='lasp.colorado.edu', url_scheme='https', url_port=443)
dummy_get = dummy_obj->get()
dummy_obj->GetProperty, RESPONSE_CODE=response_code
print, response_code

Throws an HTTP error (response code 0):

% IDLNETURL::GET: CCurlException: Error: Http Get Request Failed. Error = http: Unknown Status. Remote Host(lasp.colorado.edu), Http ErrCode(0), Http Err(content-type: text/html; charset=UTF-8) Http ErrMsg(No HTML found). % Execution halted at: $MAIN$
0

Switching to SPDF works:

dummy_obj = obj_new('IDLnetURL', url_host='spdf.gsfc.nasa.gov', url_scheme='https', url_port=443)
dummy_get = dummy_obj->get()
dummy_obj->GetProperty, RESPONSE_CODE=response_code
print, response_code

Prints 200.

Something must have changed at LASP... DDoS protections kicking-in or something?

[ericthewizard]

Update from the web team at LASP:

On Thursday, June 8th, there was a migration to a new IT load balancer used at LASP. The new load balancer requires Server Name Indication (SNI) during the TLS handshake to specify the domain (lasp.colorado.edu) for the connection. This allows the load balancer to determine the appropriate TLS certificate to use.

Clients or libraries that support TLS 1.2 or TLS 1.3 also support the SNI extension. However, some clients and libraries may only support older and less secure versions of TLS. I am working with our IT Networking team to explore the possibility of implementing a workaround. The aim is to have requests fallback to lasp.colorado.edu if the client does not support the SNI extension. Whether this is feasible or not depends on the features of the load balancer software and other system configurations.

I recommend adding or enabling SNI support for these requests. While I am not familiar with IDL to determine if the IDLnetURL object supports SNI, if it does not, it may be necessary to externalize the requests to a tool such as cURL or Python's 'requests' library.

[ericthewizard]

A fix should be in place for the SDC now! 🕺

[ericthewizard]

... and it's back ....

IDL> dummy_obj = obj_new('IDLnetURL', url_host='lasp.colorado.edu', url_scheme='https', url_port=443) IDL> dummy_get = dummy_obj->get() IDL> dummy_obj->GetProperty, RESPONSE_CODE=response_code IDL> print, response_code % Loaded DLM: URL. % IDLNETURL::GET: CCurlException: Error: Http Get Request Failed. Error = http: Unknown Status. Remote Host(lasp.colorado.edu), Http ErrCode(0), Http Err(content-type: text/html; charset=UTF-8) Http ErrMsg(No HTML found). % Execution halted at: $MAIN$
0 IDL>

[ericthewizard]

Long story short, it's back to working (after a change to the response header)!

For future reference: the server header was responding with HTTP/2 instead of HTTP/1.1, and IDL was apparently having a hard time due to that. The web team updated the response header to return HTTP/1.1, and it started working again.

The SNI issue might still be there for older versions of IDL, but I'm not sure - it's back to working for me with IDL 8.8.3.