Fixed a bug in the preview service where the CPU time limiter was overly lenient for the first several requests handled by a newly-started worker. The same bug actually exists in production as well, but we are much more cautious about fixing it there, since doing so might break live sites. If you find your worker now exceeds CPU time limits in preview, then it is likely exceeding time limits in production as well, but only appearing to work because the limits are too lenient for the first few requests. Such workers will eventually fail in production, too (and always have), so it is best to fix the problem in preview before deploying.
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
/**
* Fetch and log a request
* @param {Request} request
*/
async function handleRequest(request) {
console.log('Got request', request)
return new Response('OK', {
headers: { 'content-type': 'text/plain' },
});
}
It will not print any console.log on this specific worker (Size was just a coincidence), but it works as expected if i paste the same into another worker. And yes, I’ve cleared cache and tried different browsers, it happens only on this worker.
Could this be related to routes somehow?
Then why does it happen now, it worked before this last update.
UPDATE: Found another script it happens on, it only has one route /*.
UPDATE2: The rest of the scripts features work just as normal, it’s only console.log that won’t work.
Hi @thomas4, I was able to reproduce the issue, and it does seem like a regression. I rolled back a component that might have been causing it, and can no longer reproduce. Can you confirm?
@harris: Not sure what you just changed, but now I’m getting script exceeded time limit in the preview after a second of running, even though the script works fine outside of preview, even at multiple requests.
Another regression? I’m 90% certain it worked just a few minutes ago in preview.
Hi @thomas4, could you describe what the script does, and elaborate on “after a second of running”? Does that mean after multiple requests, or a single request that takes one second, or something else?
If you mean “after one or two requests”, then off the top of my head it sounds like the script uses a lot of CPU time and would eventually break on the edge (see the first bullet point in the release notes above).
Alternatively, I suppose that a script which uses > 50ms CPU time on the very first request, but then uses very little for all subsequent requests, would potentially never break on the edge, but exceed the CPU limit in the preview.
I respect that it might be more work than it’s worth to switch from jsrsasign to the WebCrypto API, but I’d still be curious to know which algorithms we’re missing. I would expect using the WebCrypto API (i.e., a native implementation) is always going to be the only reasonable way to do RSA signing in a worker, so it’d be great if we supported what people need.
Hmm, these I’m not sure about – do you know if there any alternate names for these? Maybe the first four are RSA-PSS, while the last three (MGF1) are RSA-OAEP?
Hi @thomas4, regarding the crypto algorithms: could you share a source for the list that you posted, or references to algorithm definitions such as RFCs or other standards? My intent is to try and map them to the conventional algorithms defined in the WebCrypto spec; failing that, to see if there is a way to define them in terms of the WebCrypto API.
The list you posted seems to imply that FIDO2 depends on three different RSA algorithms. I recognize RSASSA PKCSV15 SHA* as RSASSA-PKCS1-v1_5. I strongly suspect SHA* RSA MGF1 refers to what WebCrypto calls RSA-PSS because it is referred to in this FIDO2 spec (as RSASSA-PSS), it is the only mention I can find of MGF1 in that document, and it is the only RSA signing algorithm I am aware of that uses MGF1 (RSA-OAEP does, too, but that’s an encryption algorithm, so probably not used by FIDO2). That leaves SHA* RSA as a bit of a mystery to me.
If the FIDO2 spec says that it’s RSA-PSS then it probably is, I was using a reference to the older specs when I built that part of the implementation.
Yes, the pure JS based.
I’m currently setting up Rust to get a WASM going that will resolve the RSA verification. I’d guess this is a much faster route than you adding it to Webcrypto API, right?
