6 ms·

this really strikes me as evidence that something is wrong with the http standardization process. we should know if something's a good idea before immortalizin

by chrsig 4y ago

this really strikes me as evidence that something is wrong with the http standardization process. we should know if something's a good idea before immortalizing it in a standard. It may be removed from chrome, but it's still in the standard.

nousermane 4y ago
Well, IETF can always publish an HTTP/2.1 with that removed, no?
- chrsig 4y ago
 an HTTP/2.1 doesn't stop HTTP/2 from existing, it just creates another standard.
 - samwillis 4y ago
 HTML5 doesn’t stop XHTML from existing, however it’s collectively considered a bad idea and no one uses it. Sometimes specs are proved to be wrong, this is just one of those occasions.
 - chrsig 4y ago
 > however it’s collectively considered a bad idea and no one uses it No one uses it going forward. I'd hate to venture a guess at how many existing sites there are that use xhtml. Browsers are still expected to parse and render them properly.
 - samwillis 4y ago
 True, although in this case no one is using HTTP/2 Push, so removing it is no harm and only makes it easer to maintain browsers.
 - jraph 4y ago
 What's wrong with XHTML 1.0 or 1.1? (assuming you are speaking about this) What significant feature in XHTML is not supported by HTML5? if you are only speaking about the syntax (so your statement includes XHTML5), I don't follow you neither: I don't see what's wrong with the XML version of HTML5.
 - 0x457 4y ago
 The issue is that if the page is an invalid XHTML - it supposed not render anything at all, which is very undesirable. `` wouldn't stop HTML from rendering, but would stop XHTML. Plus the whole "XML parsers are very unsafe"
 Thiez 4y ago
 That issue is considered a feature by many. Don't send out broken web pages. If you don't build your pages using string concatenation you have already eliminated most problems (it's just like SQL, in that respect). XML parsers are not that bad when you disable custom entities, which browsers could easily do.
 0x457 4y ago
 > That issue is considered a feature by many. Don't send out broken web pages. If you don't build your pages using string concatenation you have already eliminated most problems (it's just like SQL, in that respect). Yes, but there weren't many tools to "correctly" compose XHTML back then. > XML parsers are not that bad when you disable custom entities, which browsers could easily do. Yes, but it's another thing browser developers need to think of. A lot of CVEs already originate in browser. Even if it's actually safe, people who got burnt by XML, would have bad opinions about XML in mind.
 dub 4y ago
 There's nothing stopping developers from doing server-side validation before sending markup to clients. It seems like the majority of developers have never really wanted to make that cost-benefit tradeoff, though. I ran tons of websites declaring an xhtml doctype through https://validator.w3.org/ https://validator.w3.org/ back before HTML5 when xhtml was still trendy: almost all of the "xhtml" websites failed validation.
 - vbezhenar 4y ago
 Who said noone uses it? XHTML is awesome.
BrainVirus 4y ago
>this really strikes me as evidence that something is wrong with the http standardization process. The overall decision-making around how the web works is insane and getting more insane by the year. We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Worse, some problems are finally solved in such a half-assed way that it's almost worse than having no solution at all. (Input type="date", meter element, dialog element etc.) This is not at all what I imagined the field would look like when I entered it nearly two decades ago.
- pixl97 4y ago
  >We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Why is this surprising? Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. Add to that large numbers of groups will have their own set of opinions on what the best solution is, and it will conflict with some ideas.
  - BrainVirus 4y ago
    >Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. This is completely backwards. Universal problems on the web are routinely solved by everyone designing a standard website. They often have fairly standard solutions. Browser vendors routinely fail to generalize the experience of run-of-the-mill web developers. It's not about engineering. It's about misaligned incentives and operating from a bad frame of reference.
- modeless 4y ago
  > We have fairly trivial and absolutely universal problems unsolved for decades This describes most areas of applied computer science, honestly. Language design, build systems, operating systems, etc. When standards and/or widely used systems are involved, nothing is trivial. And the web is the most widely used and most standards-based system out there.
- 4y ago
gunapologist99 4y ago
Agreed, it should have received much more testing. However, in this case it being in the HTTP/2 standard is moot, since it's just a (premature) optimization and thus its removal results in a reasonable fallback, which is simply not using that particular optimization, and also because HTTP/3 is so far along already. Not to get too tangential, but this seems similar to fetch removing support for reponse bodies for POST/PUT requests; a login POST, for example, might return information about the user's login or the state of the server, or even a per-tab/per-page token that isn't a cookie header, but fetch simply refuses to support it (even though XMLHttpRequest still does). Fetch removing this means that additional round-trips are needed, even over a multiplexed connection, and certain app designs are simply not possible. The solution seems to be to buck the trend and just use XHR instead of fetch, especially since fetch doesn't seem to be available on older Android Chrome (possibly 5-15% marketshare even now.)
- Thiez 4y ago
  > this seems similar to fetch removing support for reponse bodies for POST/PUT requests Wait what? I have never heard of that, do you have a link where this removal is documented?
  - hobobaggins 4y ago
    Maybe referring to GET, not POST/PUT bodies? https://github.com/whatwg/fetch/issues/83 https://github.com/whatwg/fetch/issues/83 Seems pretty short-sighted of a decision there, since XMLHTTPReq does it just fine, and it is in the HTTP RFC's
- chrsig 4y ago
  > it's just a (premature) optimization and thus its removal results in a reasonable fallback, which is simply not using that particular optimization this is a salient point. if it's just an optimization and not implementing it (or removal) doesn't change behavior of sites that have adopted it, then it's benign.
geofft 4y ago
But the only real way to be sure if something is a good idea, especially in complex distributed systems such as the web platform, is to try it out. And when you try it out at scale, standardization is very important. The alternative is to have everyone using new ActiveXObject("Microsoft.XMLHTTP") because you have a non-standardized thing that's rapidly turning out to be a good idea. The purpose of a standardization process isn't to stamp approval on good ideas; it's to ensure interoperability. Server Push was a plausible idea. It very much could have been a good idea. It turned out not to be, after we tried it in the real world for many years, but that's okay. And we know one thing for sure - the reason it didn't work wasn't that people were afraid to use a nonstandard X-Chrome-Server-Push extension.
- haroldp 4y ago
  That kind of seems like the difference between top-down and bottom-up standards. MS added a weird extension to IE to support their proprietary webmail app, and... actually it was great so people wanted it pulled in to every browser as a standard. Many other features from Netscape's blink to IE's scrolling marquee died natural deaths. HTTP/2 was what? Something no one wanted, imposed by Google? Is that too strong? Is bottom-up maybe better in practice?
  - uluyol 4y ago
    HTTP/2 was codeveloped by many outside of Google and was used by Facebook, Cloudflare, and others for years before being standardized.
isodev 4y ago
I would say what’s wrong is that Chrome decided to remove a standard feature, and due to their market share, nobody can oppose it. There was a time when a single company controlled the web. That was Microsoft. Today, it’s Google.
- jefftk 4y ago
  There was lots of public discussion, and no one made a serious case for keeping it. I think Chrome probably would have been happy to keep it if someone had been able to describe how it was improving performance on their site.
jgraettinger1 4y ago
Keep in mind that the HTTP/2 standardization process really started from SPDY [1]. Before HTTP/2 the standard hadn't changed significantly in _decades_ due to lack of industry consensus and actual data. Google then used its unique position as a) massive web server and b) massive web browser to perform real-world protocol experiments that _nobody_ else could possibly do. SPDY came out of that (really cool!) work, and had some great benefits, and the working group started with the spec and worked to evolve it. The server-push originally comes from SPDY, and as I recall it seemed an obviously useful optimization at the time. It's a bit ironic that the same company that introduced it is now saying "we never really found a use for it". Disclaimer: I was employed by Google and on the HTTP/2 working group at the time. 1: https://www.chromium.org/spdy/ https://www.chromium.org/spdy/
- LtWorf 4y ago
  I'm not convinced that not changing a standard that is already quite flexible is a bad thing.
- chrsig 4y ago
  That's kind of arguing against yourself though. here's a more cynical take: - "only google can do these huge experiments, and we've blessed the world by sharing our discoveries, so we can have confidence that our proposals are validated with real world experience." - "That thing we standardized and got a bunch of other people to implement? yeah, i know we said it was really useful, but we meant it seemed really useful. We actually never found a use for it." can't have it both ways
  - inopinatus 4y ago
    What it means is that the Google mindset of introducing and later killing off whatever services they feel like, extends to how they view the standards process, viz. that it’s theirs to tinker and butcher as well, and coupled to that the implicit belief that their implementation of the web is the reference implementation, and the rest of us simply subordinate to Google’s commercial preferences. Other vendors do this too - the fundamental conceit at play is as old as the tech sector - but that doesn’t make it any less arrogant or reprehensible behaviour. With that understanding, the process note above from an ex-Google employee amounts to a description of wilful abuse of market power.

by chrsig 4y ago

nousermane 4y ago

Well, IETF can always publish an HTTP/2.1 with that removed, no?

chrsig 4y ago
an HTTP/2.1 doesn't stop HTTP/2 from existing, it just creates another standard.
- samwillis 4y ago
 HTML5 doesn’t stop XHTML from existing, however it’s collectively considered a bad idea and no one uses it. Sometimes specs are proved to be wrong, this is just one of those occasions.
 - chrsig 4y ago
 > however it’s collectively considered a bad idea and no one uses it No one uses it going forward. I'd hate to venture a guess at how many existing sites there are that use xhtml. Browsers are still expected to parse and render them properly.
 - samwillis 4y ago
 True, although in this case no one is using HTTP/2 Push, so removing it is no harm and only makes it easer to maintain browsers.
 - jraph 4y ago
 What's wrong with XHTML 1.0 or 1.1? (assuming you are speaking about this) What significant feature in XHTML is not supported by HTML5? if you are only speaking about the syntax (so your statement includes XHTML5), I don't follow you neither: I don't see what's wrong with the XML version of HTML5.
 - 0x457 4y ago
 The issue is that if the page is an invalid XHTML - it supposed not render anything at all, which is very undesirable. `` wouldn't stop HTML from rendering, but would stop XHTML. Plus the whole "XML parsers are very unsafe"
 - Thiez 4y ago
 That issue is considered a feature by many. Don't send out broken web pages. If you don't build your pages using string concatenation you have already eliminated most problems (it's just like SQL, in that respect). XML parsers are not that bad when you disable custom entities, which browsers could easily do.
 0x457 4y ago
 > That issue is considered a feature by many. Don't send out broken web pages. If you don't build your pages using string concatenation you have already eliminated most problems (it's just like SQL, in that respect). Yes, but there weren't many tools to "correctly" compose XHTML back then. > XML parsers are not that bad when you disable custom entities, which browsers could easily do. Yes, but it's another thing browser developers need to think of. A lot of CVEs already originate in browser. Even if it's actually safe, people who got burnt by XML, would have bad opinions about XML in mind.
 dub 4y ago
 There's nothing stopping developers from doing server-side validation before sending markup to clients. It seems like the majority of developers have never really wanted to make that cost-benefit tradeoff, though. I ran tons of websites declaring an xhtml doctype through https://validator.w3.org/ https://validator.w3.org/ back before HTML5 when xhtml was still trendy: almost all of the "xhtml" websites failed validation.
 - vbezhenar 4y ago
 Who said noone uses it? XHTML is awesome.

BrainVirus 4y ago

>this really strikes me as evidence that something is wrong with the http standardization process. The overall decision-making around how the web works is insane and getting more insane by the year. We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Worse, some problems are finally solved in such a half-assed way that it's almost worse than having no solution at all. (Input type="date", meter element, dialog element etc.) This is not at all what I imagined the field would look like when I entered it nearly two decades ago.

pixl97 4y ago
>We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Why is this surprising? Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. Add to that large numbers of groups will have their own set of opinions on what the best solution is, and it will conflict with some ideas.
- BrainVirus 4y ago
  >Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. This is completely backwards. Universal problems on the web are routinely solved by everyone designing a standard website. They often have fairly standard solutions. Browser vendors routinely fail to generalize the experience of run-of-the-mill web developers. It's not about engineering. It's about misaligned incentives and operating from a bad frame of reference.
modeless 4y ago
> We have fairly trivial and absolutely universal problems unsolved for decades This describes most areas of applied computer science, honestly. Language design, build systems, operating systems, etc. When standards and/or widely used systems are involved, nothing is trivial. And the web is the most widely used and most standards-based system out there.
4y ago

gunapologist99 4y ago

Agreed, it should have received much more testing. However, in this case it being in the HTTP/2 standard is moot, since it's just a (premature) optimization and thus its removal results in a reasonable fallback, which is simply not using that particular optimization, and also because HTTP/3 is so far along already. Not to get too tangential, but this seems similar to fetch removing support for reponse bodies for POST/PUT requests; a login POST, for example, might return information about the user's login or the state of the server, or even a per-tab/per-page token that isn't a cookie header, but fetch simply refuses to support it (even though XMLHttpRequest still does). Fetch removing this means that additional round-trips are needed, even over a multiplexed connection, and certain app designs are simply not possible. The solution seems to be to buck the trend and just use XHR instead of fetch, especially since fetch doesn't seem to be available on older Android Chrome (possibly 5-15% marketshare even now.)

Thiez 4y ago
> this seems similar to fetch removing support for reponse bodies for POST/PUT requests Wait what? I have never heard of that, do you have a link where this removal is documented?
- hobobaggins 4y ago
  Maybe referring to GET, not POST/PUT bodies? https://github.com/whatwg/fetch/issues/83 https://github.com/whatwg/fetch/issues/83 Seems pretty short-sighted of a decision there, since XMLHTTPReq does it just fine, and it is in the HTTP RFC's
chrsig 4y ago
> it's just a (premature) optimization and thus its removal results in a reasonable fallback, which is simply not using that particular optimization this is a salient point. if it's just an optimization and not implementing it (or removal) doesn't change behavior of sites that have adopted it, then it's benign.

geofft 4y ago

But the only real way to be sure if something is a good idea, especially in complex distributed systems such as the web platform, is to try it out. And when you try it out at scale, standardization is very important. The alternative is to have everyone using new ActiveXObject("Microsoft.XMLHTTP") because you have a non-standardized thing that's rapidly turning out to be a good idea. The purpose of a standardization process isn't to stamp approval on good ideas; it's to ensure interoperability. Server Push was a plausible idea. It very much could have been a good idea. It turned out not to be, after we tried it in the real world for many years, but that's okay. And we know one thing for sure - the reason it didn't work wasn't that people were afraid to use a nonstandard X-Chrome-Server-Push extension.

haroldp 4y ago
That kind of seems like the difference between top-down and bottom-up standards. MS added a weird extension to IE to support their proprietary webmail app, and... actually it was great so people wanted it pulled in to every browser as a standard. Many other features from Netscape's blink to IE's scrolling marquee died natural deaths. HTTP/2 was what? Something no one wanted, imposed by Google? Is that too strong? Is bottom-up maybe better in practice?
- uluyol 4y ago
  HTTP/2 was codeveloped by many outside of Google and was used by Facebook, Cloudflare, and others for years before being standardized.

isodev 4y ago

I would say what’s wrong is that Chrome decided to remove a standard feature, and due to their market share, nobody can oppose it. There was a time when a single company controlled the web. That was Microsoft. Today, it’s Google.

jefftk 4y ago
There was lots of public discussion, and no one made a serious case for keeping it. I think Chrome probably would have been happy to keep it if someone had been able to describe how it was improving performance on their site.

jgraettinger1 4y ago

Keep in mind that the HTTP/2 standardization process really started from SPDY [1]. Before HTTP/2 the standard hadn't changed significantly in _decades_ due to lack of industry consensus and actual data. Google then used its unique position as a) massive web server and b) massive web browser to perform real-world protocol experiments that _nobody_ else could possibly do. SPDY came out of that (really cool!) work, and had some great benefits, and the working group started with the spec and worked to evolve it. The server-push originally comes from SPDY, and as I recall it seemed an obviously useful optimization at the time. It's a bit ironic that the same company that introduced it is now saying "we never really found a use for it". Disclaimer: I was employed by Google and on the HTTP/2 working group at the time. 1: https://www.chromium.org/spdy/ https://www.chromium.org/spdy/

LtWorf 4y ago
I'm not convinced that not changing a standard that is already quite flexible is a bad thing.
chrsig 4y ago
That's kind of arguing against yourself though. here's a more cynical take: - "only google can do these huge experiments, and we've blessed the world by sharing our discoveries, so we can have confidence that our proposals are validated with real world experience." - "That thing we standardized and got a bunch of other people to implement? yeah, i know we said it was really useful, but we meant it seemed really useful. We actually never found a use for it." can't have it both ways
- inopinatus 4y ago
  What it means is that the Google mindset of introducing and later killing off whatever services they feel like, extends to how they view the standards process, viz. that it’s theirs to tinker and butcher as well, and coupled to that the implicit belief that their implementation of the web is the reference implementation, and the rest of us simply subordinate to Google’s commercial preferences. Other vendors do this too - the fundamental conceit at play is as old as the tech sector - but that doesn’t make it any less arrogant or reprehensible behaviour. With that understanding, the process note above from an ex-Google employee amounts to a description of wilful abuse of market power.