ETagged integration with ETag header definition in response struct

[pboguslawski]

When using ETagged to populate ETag header, one cannot define ETag in response struct because value from struct overrides one generated with ETagged.

Using ETag header definition in response struct allows one to make it present in openapi.json, to make it required header, validate response with it, etc.; ETagged doesn't allow it.

Consider integrating ETagged solution with ETag header definition in response struct: when both are defined and ETag header value in response struct is empty, use value generated with ETagged but validate it against format defined in response struct for ETag response header; if ETag header value is non-empty in response struct - validate it and use it instead of ETagged value.

BTW: canonical ETag header name should be used in https://github.com/swaggest/rest/blob/master/response/encoder.go#L319 probably.

[vearutop]

Can you explain your scenario in more details? Why do you need ETagged if you have ETag field (or could your goal be achieved with ETag struct field alone)?

re BTW: canonical has different definition as per Go implementation, first char and every first char after - is capitalized, all the rest are lowercase. So if you pass ETag to map of headers, it will be converted to Etag at the cost of extra allocation for a new string.

[pboguslawski]

Why do you need ETagged if you have ETag field (or could your goal be achieved with ETag struct field alone)?

One can define "default" ETagged way of generating ETag header for given struct and still be able to customize ETag generation for specific interactor using this response struct (overriding ETagged generated stuff). This is just "nice to have" and may be ignored if hard to implement (if want to use ETagged, developer must do it without ETag header defined in response struct).

canonical has different definition as per Go implementation, first char and every first char after - is capitalized

"BTW" was about HTTP header name (which should be canonical HTTP ETag) not about name of go field name in struct. Go should probably not change header names specified in header:"" (HTTP response should preserve exact case as specified in header:"") and when comparing - do it in case insensitive fashion (don't know swaggests internals well so maybe I'm wrong).

[vearutop]

Yeah, I was also talking about header name.

Go uses their own definition of a canonical header name (and they have a right to define any strategy, including eTaG or ETAG), ETag is not a canonical name per that definition, Etag is.

As an implementation detail, header name is converted to canonical form on write (.Set), so that during lookup (.Get) the header could be found in a map with O(1) instead of O(n).

golang/go#18476

[pboguslawski]

Go uses their own definition of a canonical header name

Thanks for explanation. So it's better to use Etag as header name indeed :)