Surrogate-Control headers

[ryanschneider]

It looks like this package does not support the less common Surrogate-Control header sometimes used by CDNs.

The logic to support Surrogate-Control would basically the same as Cache-Control, but the header is specifically meant for reverse proxy <-> origin server controls (Cache-Control is meant for end browsers).

See: https://www.w3.org/TR/edge-arch/

Often used by CDNs:
https://docs.fastly.com/guides/tutorials/cache-control-tutorial
https://www.nuevocloud.com/documentation/getting-started/cache-headers-cache-control-surrogate-control-and-expires

See nicolasazrak/caddy-cache#24 for discussion.

[pquerna]

I think basic support could be done today using the low level api, eg by populating Object.RespDirectives with the parsed results of ParseResponseCacheControl(respHeaders.Get("Surrogate-Control")):
https://godoc.org/github.com/pquerna/cachecontrol/cacheobject#Object

Having said that, adding a field to the options object would also let this work using the high level API and remain compatible with existing API users too:
https://godoc.org/github.com/pquerna/cachecontrol#Options

[ryanschneider]

Ya, I was looking in those areas, my naive first pass was to update UsingRequestReponse like so:

        var reqDir *RequestCacheDirectives = nil
	ctrlHeader := "Cache-Control"
	if respHeaders.Get("Surrogate-Control") != "" {
		ctrlHeader = "Surrogate-Control"
	}

	respDir, err := ParseResponseCacheControl(respHeaders.Get(ctrlHeader))
	if err != nil {
		return nil, time.Time{}, err
	}

Which is to say, use the Surrogate-Control header if its there, otherwise fallback to Cache-Control, but I agree that making it controllable via Options would be good, so I'll look into how that could be done.