Add safelisted cors header subfeature

[hamishwillee]

Fixes #9300

@ddbeck As we discussed in #9300 this is update adds subfeature for "CORS response header safelist" for two response headers as a test (on completion this will cover all the headers

The Content-Length update is the interesting one, which adds the browser versions at which the header joined the list. The linked item covers the versioning discussion except for Safari. I have marked that as false because it is still in the technology preview: https://developer.apple.com/safari/technology-preview/release-notes/

The Cache-Control is what all the other ones will look like. Essentially it just copies the version info from the parent - my assumption being that the header and the safelist came at the same time. This is reasonable, because most of these headers just say true for version anyway.

If you're OK with the approach/text I will roll out to the other headers in the list.

[ddbeck]

Apart from a couple very minor things in line comments, I think this looks reasonable in terms of data and structure. But since there's something novel in the structure of this…

@Elchi3 would you mind giving this a glance? It's not a huge thing, but this is going to lead to several new features with a common naming scheme and I'd like another owner perspective.

[Elchi3]

LGTM! I'm not sure it is needed to add this to all headers that had this from the beginning, though.
How does this enhance the Cache-Control compat table? The docs already mention whether or not Cache-Control is a CORS safe listed header. Why would the compat table need to repeat that and just show the same basic support data?

[hamishwillee]

@Elchi3

LGTM! I'm not sure it is needed to add this to all headers that had this from the beginning, though.

Then how would you know that a header was compatible or not from the data? i.e. if Cache-Control does not have the feature that might indicate that it isn't compatible at all.

How does this enhance the Cache-Control compat table? The docs already mention whether or not Cache-Control is a CORS safe listed header. Why would the compat table need to repeat that and just show the same basic support data?

It doesn't. Where this helps is for Content-Length and any other future header that gets added to the list. If this goes in though, you could in theory decide to autogenerate the info in the docs from the compatibility table.

It is completely reasonable to argue that this feature is only affecting one header and we might as well just have a note in the docs. But for me this seems like the purpose of the compatibility table. Up to you guys.

[Elchi3]

Then how would you know that a header was compatible or not from the data? i.e. if Cache-Control does not have the feature that might indicate that it isn't compatible at all.

In my view, the compat table communicates what doesn't work. It is not there to communicate everything that works.
The Cache-Control compat table doesn't even list all directives that work either. These are implicitly included in the basic support for Cache-Control (first row in the table). My assumption is that the reader can assume that things work if they are not listed in the table.

It doesn't. Where this helps is for Content-Length and any other future header that gets added to the list.

Right, when support is added after a feature initially ships, there is a usually a sub feature in BCD: So, safe listed CORS header makes a lot of sense for Content-Length. Completely agree on this case.

[ddbeck]

Thanks for the discussion here, @hamishwillee and @Elchi3. This has been clarifying, I think. After reading it, I think this PR can be reduced to the cors_response_safelist feature in Content-Length and then we don't need to add any additional features (until a new safelisted header comes along). Does that make sense for everyone?

[hamishwillee]

I think this PR can be reduced to the cors_response_safelist feature in Content-Length and then we don't need to add any additional features (until a new safelisted header comes along). Does that make sense for everyone?

This will work - anyone coming to Content-Length will recognise the behaviour of this header has some non standard behaviour.
I get confused because I expect to be able to go to any doc and see that a feature is supported or not.

Anyway, thanks guys. Changed as suggested.

[Elchi3]

Thanks @hamishwillee 👍