Added new exposeTaffyHeaders

[dswitzer]

This PR add support for a new exposeTaffyHeaders setting, which is true by default to preserve backwards compatibility.

When set to false, it will prevent the following headers from being sent in the HTTP response:

• X-TAFFY-RELOADED
• X-TIME-TO-RELOAD
• X-TIME-IN-PARSE
• X-TIME-IN-ONTAFFYREQUEST
• X-TIME-IN-RESOURCE
• X-TIME-IN-CACHE-CHECK
• X-TIME-IN-CACHE-GET
• X-TIME-IN-CACHE-SAVE
• X-TIME-IN-SERIALIZE
• X-TIME-IN-TAFFY
• X-TIME-IN-ONTAFFYREQUESTEND

I also updated the documentation to document what each of these headers means (at least based on my understanding).

My intention was to include unit tests for this, but I was running into tons of issues trying to get the unit tests running in Commandbox. The documentation here seems be very outdated.

[netlify]

✅ Deploy Preview for taffy-docs ready!

Name	Link
🔨 Latest commit	3408832
🔍 Latest deploy log	https://app.netlify.com/projects/taffy-docs/deploys/68b1bbfb8aa59d0008228cbc
😎 Deploy Preview	https://deploy-preview-451--taffy-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[atuttle]

Overall a fantastic PR. One little note for the docs.

[JamoCA]

Will this be something that can be toggled and enabled via a web request. If I were testing something and wanted to enable all the headers (which are now globally disabled), would there be a way to pass a "secret" URL param or header to enable "exposeTaffyHeaders" during a request?

I'm inquiring because I currently use browser extensions (like Requestly) to inject HTTP request headers (with encrypted values) to configured hostnames to enable extra features - like enabling debugging, A/B testing, enable feature flags, etc.

[dswitzer]

Since it's a setting, you can use the environmental settings to enable it by environment, so you could enable it for a "dev" environment, but leave it disabled for production.

If you do nothing, it has the same behavior as before.

However, given that Taffy stores settings in the application scope, having it behavior differently on a request-by-request nature isn't really possible.

[JamoCA]

I'd like both options to be available so I don't have to choose between two different environments. If something doesn't seem to be working correctly in production, I'd like the option to pass a secret param to enable the headers to assist in troubleshooting.

Similar request override features already exist for application settings... See debugKey, reloadKey, reloadPassword configuration settings.

I reported an issue regarding ColdFusion content flushing occurring before Taffy could add headers Taffy resulting in CF errors. Instead of using the built-in functions, Taffy could collect them (regardless of whether exposeTaffyHeaders is enabled or not) and then output them at the end of the request if content has not already been flushed and if exposeTaffyHeaders=true or the request-based override exists.

As an example, our web application framework collects all informational (non-essential) header data and outputs them at the end of the request IF the content hasn't already been flushed. This also enables us to negate or overwrite any headers as needed.

[dswitzer]

I'd argue that you can certainly code this behavior if it's important to you. Add a feature so you can toggle the behavior. You would just need to change the application._taffy.settings.exposeTaffyHeaders.

I'm personally not a fan of URL parameters that can alter the behavior of the REST API, because that leaves you open to unexpected issues.

For you use case, you might just want to just leave the headers enabled so there's no change in behavior and the headers are always sent. I just didn't want the headers, because they leak information that could be used as an attack vector (i.e. they reveal the REST API is using Taffy).

[dswitzer]

Oh, I should add, since I refactored the adding of Taffy headers to it's own function, you could just overwrite the method for your implementation.

This is the default implementation:

<cffunction name="addTaffyHeader">
	<cfargument name="name" type="string" required="true" />
	<cfargument name="value" type="string" required="true" />

	<cfif application._taffy.settings.exposeTaffyHeaders>
		<cfheader name="#arguments.name#" value="#arguments.value#" />
	</cfif>
</cffunction>

You could just override that in your Application.cfc and use something like:

<cffunction name="addTaffyHeader">
	<cfargument name="name" type="string" required="true" />
	<cfargument name="value" type="string" required="true" />

	<cfif url.keyExists("my_special_param") and url.my_special_param eq "my_key">
		<cfheader name="#arguments.name#" value="#arguments.value#" />
	</cfif>
</cffunction>

Then Taffy would ignore the exposeTaffyHeaders setting completely and only write the headers when the URL matches. You could obviously check a header or anything else coming in. I'd just recommend keeping the logic light since the function is called frequently (you could store a setting in the Request scope so the logic is only performed once.

[dswitzer]

Alternatively, instead of adding the information to the headers, you could redirect the output to a log.

Lots of options.