[LiveComponent] Switch to text/vnd.ux-live-component

[smnandre]

RFC: use text/html or txt/vnd.ux-live-component

To improve DX and align with IANA, we can:

• use a more "standard" custom ContentType header (txt/vnd.ux-live-component)
• use text/html and add another header to check front/back exchanges

Or we can keep current one :)

---

LiveComponent currently require the application/vnd.live-component+html header in both communication from both browser and server when communicating.

This header has the disadvantage to not be show in browser developer tools (Chrome and Firefox can only display the content after a couple of clicks.. for every request).

The other problem is that it seems a bit .. wrong. Or let's say not perfectly in line with the different RFC.

subtype

Text

It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to present subtypes of "text" to the user, while it is not reasonable to do so with most non-textual data. Such formatted textual data can be represented using subtypes of "text".

Application

The "application" top-level type is to be used for discrete data that do not fit under any of the other type names, and particularly for data to be processed by some type of application program. This is information that must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" type name include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material.

So i feel we are more in line with text here.

vendor

We should register our vendor names to be perfectly in line with the RFCs, but i guess none of us has the time, energy, and need to do such thing.

suffix

+html is not a valid suffix (see full list of suffixes). This is recommanded both for official mime registration but also as general practice

[javiereguiluz]

Based on your information, text/html seems the best option here.

But, I don't know internals well enough to see if changing the current content-type header will break something for someone.

[nicolas-grekas]

But this is not valid html, so text/html would be incorrect, isn't it?
Also, a custom content-type is currently how the CSRF protection works.
This can be replaced with another header, but this should be accounted for.

[smnandre]

But this is not valid html, so text/html would be incorrect, isn't it?

Gray area... let's say it would not not be "full - html- document - valid"... but what we send is HTML (part of document but still)

In the end, to be 100% honnest, this header works and will continue to work.

The main problem is the DX one.

And i won't fight for this if it created trouble for a single user
(this is where i will obv listen to and follow you guys)