You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FetchEvent.client is of type ClientInfo, which contains information about the currently connected client.
One thing to note is, these crashes do not occur when deployed to Fastly Compute.
Reading some of these fields in Viceroy (including fiddle) causes crashes, starting with js-compute@3.x (the problem does not happen in js-compute@2.x): 'tlsJA3MD5', 'tlsCipherOpensslName', 'tlsProtocol', 'tlsClientCertificate', 'tlsClientHello'.
The error I get is something like this:
Error while running request handler: tls_cipher_openssl_name_get: A `None` error. This status code is used to indicate when an optional value did not exist, as opposed to an empty value.
NOTE: In Fiddle the error looks like this:
tls_cipher_openssl_name_get: Generic error value. This means that some unexpected error occurred during a hostcall.
This means that simply trying to perform a console.log(event.client) in local development will cause a crash.
However, these crashes do not occur when deployed to a Fastly service. The reason for this I'm speculating may be because these fields always have values on Fastly.
I noticed this because a library I had written back in js-compute@2 started crashing in a debug logging statement after switching to js-compute@3, but only on local dev.
FetchEvent.client
is of typeClientInfo
, which contains information about the currently connected client.One thing to note is, these crashes do not occur when deployed to Fastly Compute.
Reading some of these fields in Viceroy (including fiddle) causes crashes, starting with js-compute@3.x (the problem does not happen in js-compute@2.x):
'tlsJA3MD5', 'tlsCipherOpensslName', 'tlsProtocol', 'tlsClientCertificate', 'tlsClientHello'
.The error I get is something like this:
This means that simply trying to perform a
console.log(event.client)
in local development will cause a crash.However, these crashes do not occur when deployed to a Fastly service. The reason for this I'm speculating may be because these fields always have values on Fastly.
I noticed this because a library I had written back in js-compute@2 started crashing in a debug logging statement after switching to js-compute@3, but only on local dev.
I have a repro here: https://fiddle.fastly.dev/fiddle/adac0871
The text was updated successfully, but these errors were encountered: