[zare_st]

This is somewhat stupid from my angle (the W3C recommendation).

I don't expect that url.html is a static html file. I expect it to be server-side generated in 2024. For me site.com/page and site.com/page.html are the same. I do not expect different behavior from my web client side. So I may switch backend engine every year, and I'll just route the request sfrom page.html and that's it.

What's way worse than this is using non-HTML extensions for emitting html. I go to pichost.com/image.jpg and I get a webpage served. This is a bad pattern and it needs to go away. I'm not even going into responding differently depending on user-agent or referrer, if you have combination of these you get JPG returned, if you don't you get a webpage returned.

[account42]

> What's way worse than this is using non-HTML extensions for emitting html. I go to pichost.com/image.jpg and I get a webpage served. This is a bad pattern and it needs to go away. I'm not even going into responding differently depending on user-agent or referrer, if you have combination of these you get JPG returned, if you don't you get a webpage returned.

It's mostly based on the Accept header these days (browsers don't tend to include HTML there in image contexts) and the Referer should have been removed decades ago. This means browsers (the ones with a large market share at least) are 100% complicit in enabling this behavior.

[Symbiote]

The HTTP standard specifies this behaviour.

HTTP has no concept of a file extension.

[MrVandemar]

> I don't expect that url.html is a static html file. I expect it to be server-side generated in 2024.

Needless complexity if all you need is best served by a static html file.

[zare_st]

Agreed... but not what I was talking about. HTTP has no files or extensions, it's just URL that someone named dot something. Since it doesn't have to be that file type behind, I don't expect it to.