adding string to end of union used for content-type header results in error

[swathipil]

Link to repro in playground [here].

In SchemaRegistry, we want to the content type header to be a union of values. This does not compile when string is added to the end of the union, and fails with:

contentType parameter must be a string literal or union of string literals

It works when string; on line 66 of the playground link above is removed. However, it should work when string is added to the end. It also works when the header is renamed to something else, so it seems to be a bug with using the "Content-Type" header specifically.

May be related to #2727

[markcowl]

• relax this requirement in http (allow open string, but not non-string types)
• open content-types should use a bytes type payload (linter -> warning diagnostic)
• allow string
• should we allow wildcard types explicitly as literals without an open string variant (e.g. application/*, /)
• Add linter rule to Azure.Core to encourage explicit enumeration of allowed content-types

In responses:

• wildcard types imply an 'accepts' header.

[markcowl]

• discuss with dpg team, need to design support (if any) in TCGC

[markcowl]

@markcowl discuss with DPG and then file impl issues

[catalinaperalta]

@markcowl do we have an impl issue for this? And do you know what sprint it is planned for?

[swathipil]

Hi @markcowl - Any updates on when this will be addressed? We have a service where this issue will block the release of this service: Azure/azure-rest-api-specs#25168 (comment)

[markcowl]

@swathipil This service spec has been merged.

[swathipil]

thanks @markcowl! We merged the spec, but added a TODO comment in the spec to address the issue as soon as the fix for this is in. We're still blocked from releasing any SDKs generated by this spec until this issue is addressed.

[swathipil]

Hi @markcowl - We're blocked from releasing our SDKs by this issue (as per comment above), and we plan on releasing this upcoming release week. Do you know when this will be addressed?

[timotheeguerin]

I believe what was decided is that the way to do so was to specify a wildcard content type and that string could automatically imply that but it isn't blocking you.

https://typespec.io/playground?c=aW1wb3J0ICJAdHlwZXNwZWMvaHR0cCI7Cgp1c2luZyBUeXBlU3BlYy5IdHRwOwpAc2VydmljZSh7CiAgdGl0bGU6ICJXaWRnZXQgU8YbIiwKfSkKbmFtZXNwYWNlIERlbW%2FHGzsKCm9wIHVwbG9hZChAaGVhZGVyIGNvbnRlbnTEaTogIiovKiIsIEBib2R5yBo6IGJ5dGVzKTogdm9pZDsK&e=%40typespec%2Fopenapi3&options=%7B%22linterRuleSet%22%3A%7B%22extends%22%3A%5B%22%40typespec%2Fhttp%2Fall%22%5D%7D%7D

Now do client emitter actually support that is another question.

[swathipil]

We were able to test out the scenario that we believed would have been blocking, and it passed. Can confirm that this is non-blocking. Thanks @timotheeguerin!