Greetings @swamidass 
I’ve noted your responses across a few different threads in the last couple of weeks but figured I’d hop in on this one since @coelmay tagged one of my other threads 
When I first read your OP on this thread my idea was essentially “Sure, you can setup 200/304 (HTTP caching via etags) but you’re going to have to do it yourself” along with “if you’re generating the PDF on-the-fly you’ll either need to store it somewhere external or have some form of oracle to validate whether the browser’s copy is still fresh given the transient nature of Functions”. It appears you’ve done both of those things. Neat! 
If I understand your code and workflow correctly, you are indeed receiving the Function request and dispatching a 200 (with a regenerated PDF) or a 304 based on whether the incoming etag is valid against your oracle — which in this case sounds like is some kind of HTML document that you presumably populate and collate into a PDF. I think this is a perfectly fine setup and pushing the caching directly to the browser like this is neat.
I think where you may be running into trouble
Is that indeed, your Function response is being cached at the Netlify level rather than being run at all (to determine whether a 200/regen or 304 should be returned). I’m not sure if it’s outlined in the docs anywhere but essentially the idea is that if you use the cache-control header, Netlify will effectively interject in future requests having ‘learned’ the cache pattern for that particular URL (query strings are ignored, FYI). See here (and here).
So the way to ‘fix’ this would be to not use the cache-control header while still implementing etags — granted, I don’t know how proper or correct that is, I haven’t worked with cache headers in a little while and would need to read up on the spec for that… but hopefully this sheds some light on your issue.
Hope that helps!
–
Jon