Suggested changes

[finestructure]

Allow CFRay logging based on env variable

ENABLE_CF_RAY_LOGGING is set to true in dev and prod now.

[heckj]

since this is replacing the request middleware, if it’s disabled there will be no middleware logging requests. I’m assuming that’s needed for logs, so we might want to revise this down the road to replacing or not in config on the env variable, rather than enabling or disabling in the middleware.

Hard to read on an iphone, but i think that’s what I’m seeing.

[finestructure]

Oh, right. I thought by forwarding to the next responder it'd be a no-op but now I recall that you're replacing the default middleware, don't you?

I'll test the impact on dev after I'm done with the redis stuff.

[finestructure]

I've simply moved the environment.enableCFRayLogging() out of the middleware and up to the configure level, where it keeps current behaviour if ENABLE_CF_RAY_LOGGING is set to false.

[finestructure]

Also, since we've got redis now I wonder if we actually want to send the CFRay headers to the logs rather than straight into redis. Might be easier to extract?

[heckj]

I wanted to start with it just going into logging so that I could see exactly how clustered normal usage was when viewed through the aggregate lens of a cf-ray identifier. I know it's broader than an IP address, but don't have a really good sense, so I'm hoping to getting logging kicking earlier and visible to see how things aggregate in production prior to assembling any rate limiter - either classic mode (429 responses and refusal) or honeypot slow-downs.

I had no idea which way would be easier to extract - just straight in the logs, or tossed into the log metadata. I'm totally game either way.