Hi!
Thanks for the reply.
The incoming request headers are somewhat manipulated and you are right, for instance "X-Forwarded-For" is added and as a service to my app, it tells me the source request ip address. Then my app and my jetty web server handles the request. I remove all response headers and send the reply. It goes through Google Frontend again. They would remove "server" and such if I set them and instead they add these 5 response headers to the reply. Even if I do not want it. Moreover, I do not see how I could tell Google Frontend from my application that it should not add any response headers.
It makes sense that they set these response headers, normally. The problem is, I cannot tell from my App Engine application not to set them, in special cases. And still, these 100 bytes are counted towards my bill. My app is public and if I get a DDoS like attack, even if I served zero content, App Engine adds these 100 byte response headers to hundreds of request per second(!) and I am going to be billed for it.
It is not a question for stackoverflow because I am 95% sure now I cannot change this behavior of App Engine... my question is
1. is it true or there exists an option to make App Engine (Google Frontend) behave exactly as I want it (in special cases, skip adding these aforementioned response headers... I tested it, I send absolutely zero content and headers and these 5 are added before the response leaves Google Frontend... it is client -> GoogleFrontend -> my app with my embedded jetty server -> Google Frontend (here happens the unwanted byte-adding) -> client)
2. then I guess I would have a feature request to be able to tell App Engine that I want a completely header free response for security/financial reasons
It would be also ok for me if I werent billed for these bytes that are always added.
Security and request handling is a common responsibility in App Engine. These added response headers are a (financial) security threat in serverless architectures like the pay as you go App Engine.
I myself cannot really close this attack surface with session management because the first requests to "/" are inherently public. I think it is somewhat theoretical because 100 bytes are not that much, still it makes my wallet bleed in case of an http flood attack. For no good reasons, apparently. Or for none that I am aware of.
Could you please point me somewhere if this is not the right place where could I get an explanation why I am forced to play extra dollars/euros in case of an attack? Or where can I make a feature request?
My suggested solution:
1. I should be able to tell Google Frontend to skip adding anything to the requests or at least to the inherently public request to "/"
2. or if they add these response headers (100 bytes) for no good reason they should not bill me for them
Thanks!