So put them on separate pages because they are separate protocols (HTML for the browser and XML for a feed reader), with a link on the HTML page to be copied and pasted into a feed reader.
It really feels like the developer has over-constrained the problem to work with browsers as they are right now in this context.
There are separate URLs for "https:" vs "http:" although they are usually the same content when both are available (although I have seen some where it isn't the same), although the compression (and some other stuff) is decided by headers. However, it might make sense to include some of these things optionally within the URL (within the authority section and/or scheme section somehow), for compression, version of the internet, version of the protocol, certificate pinning, etc, in a way that these things are easily delimited so that a program that understands this convention can ignore them. However, that might make a mess.
I had also defined a "hashed:" scheme for specifying the hash of the file that is referenced by the URL, and this is a scheme that includes another URL. (The "jar:" scheme is another one that also includes other URL, and is used for referencing files within a ZIP archive.)
> Would you also suggest I use separate URLs for HTTP/2 and HTTP/1.1? Maybe for a gzipped response vs a raw response?
The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.
> It's the same content, just supplied in a different format. It should be the same URL.
So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format.
> The difference between HTTP/2 and HTTP/1.1 is exactly like the difference between plugging your PC in with a green cable or a red cable. The client neither knows nor cares.
Just like protocol negotiation, HTTP has format negotiation and XML postprocessing for exactly the same reason.
> So what do I put as the URL of an MP3 and an Ogg of the same song? It's the same content, just supplied in a different format
Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.
Similarly, it makes sense to return an XML with XSLT for most browsers and a degraded experience with just a simple text file for legacy browsers such as NCSA Mosaic or 2027's Google Chrome.
> Whatever you want? If I access example.org/example.png, most websites will return a webp or avif instead if my browser supports it.
So, you need a lot of cleverness on the browser to detect which format the client needs, and return the correct thing?
Kind of not the same situation as emitting an XML file and a chunk of XSLT with it, really.
If you're going to make the server clever, why not just make the server clever enough to return either an RSS feed or an HTML page depending on what it guesses the client wants?
Then the server should supply the right format based on the `Accept` header, be it `application/rss+xml` or `application/atom+xml` or `text/xml` or `text/html`.
Even cheaper than shipping the client an XML and an XSLT is just shipping them the HTML the XSLT would output in the first place.
How many people out of the world's nearly eight billion population, would you estimate, are attempting to host their blog including HTML posts and RSS feeds on an Arduino?