PDF/A validation on serverless and edge runtimes

Validation needs to be fast to be practical for every request. If the validator has to do setup work before it can check the file, you pay that cost every time the function runs. If the function has to start from scratch for each request, any setup the validator does gets repeated instead of being reused.

Where it fits

The measurements behind that table, and the methodology they were taken under, are on the benchmarks page.

Validating in the browser

Compiled with GOOS=js GOARCH=wasm, the same gopdfrab engine runs in a Web Worker. That changes the privacy story completely: the document is read into memory in the visitor's browser and handed to the WebAssembly module, and there is no endpoint that could receive it. The validator on this site works exactly that way.

Bounding memory

A function with a memory cap and untrusted input is exactly the situation the resource limits exist for. A single stream decodes to at most 256 MB by default.

// A single stream decodes to at most 256 MB by default, guarding against
// decompression bombs. Raise it for legitimately large PDFs, or lower it to
// harden against hostile input.
gopdfrab.SetLimits(gopdfrab.Limits{
	MaxDecodedStreamBytes: 512 << 20, // 512 MB
	MaxResidentBytes:      32 << 20,  // caches one open document keeps (default 64 MB)
})

gopdfrab.CurrentLimits()  // the effective caps
gopdfrab.DefaultLimits()  // the built-in caps

Cancellation

The verifier uses deadlines, so a problematic document is abandoned rather than running until the platform terminates the invocation. See options and cancellation.

Frequently asked