9 ms·

Seeing how long we have used http 1.0/1.1 (and still); and http/2.0 far from fully adopted, I'm somewhat surprised to see v3 being discussed already and v4 bein

Seeing how long we have used http 1.0/1.1 (and still); and http/2.0 far from fully adopted, I'm somewhat surprised to see v3 being discussed already and v4 being mentioned in there. Though maybe it requires way more future vision and planning then I expect.

gcb0 8y ago
its all mostly driven by Google pushing thu with chrome constant updates. they can update chrome tomorrow to v3, v4, v10... it's all the same. on http2/spdy, they at least had the decency to publish something before forcing everyone into adoption
- gregmac 8y ago
  It helps that this also pushed the other browser vendors to step up their games. Firefox switched to a Rapid Release cycle. Even Microsoft is now on board with Edge updating fairly regularly (at least compared to IE). A few years ago, web sites and infrastructure had to be built to serve decade-old versions. Now it's reasonable to support only a few years-old versions, and this time frame is continuously shrinking as the current generation of evergreen auto-updating browsers takes more market share. Though I don't like the bit about forcing adoption onto others, I do think that advancing the market to allow standards changes like this to happen in years instead of decades is a good thing.
  - h1d 8y ago
    Too bad Windows 10 isn't exactly everyone's favorite and thus IE is still around for some time.
  - gcb0 8y ago
    dont drink google coolaid! they all already have ways to release security patches. firefox has a semi-secret/invisible system addon for that. so much that this is still the current way to release security patches and fix internet-breaking bugs. rapid release for new features eas invented by microsoft with IE, to push the agenda on standards bodies. it moved so fast that nonody even remember IE5 or 5.5... and thats the reason google have rapid release. nothing to do with security, as proved on the 1st paragraph.
nextweek2 8y ago
What you are seeing is someone picking up the baton and running with it. HTTP 1.1 has drawbacks which we've been living with for far too long. Getting people used to change was step one, that was HTTP/2, now were in a position to fix pain points. I'd also like to see updates to IMAP, SMTP and FTP to name a few.
- numbsafari 8y ago
  I'm with you on IMAP and SMTP, as they serve a specific purpose. One thing I don't understand, is why anyone is holding on to FTP at this stage over HTTP. Outside of legacy enterprise "file transfer" appliances, which I deal with all day and can appreciate the inertia around, I just don't understand what the benefit is over HTTP.
  - drb91 8y ago
    There’s no standard for HTTP file uploads, with all the permissions that come along with it. Eg you can POST a file to a path, but the behavior is undefined, as is authorization, etc. S3 is probably the closest thing to replacing FTP, and I would hazard a guess that there just isn’t sufficient reason to dump ftp and upgrade infrastructure. Ftp is surprisingly common when integrating between parties, and this can be expensive to change for non technical reasons.
    - treve 8y ago
      The standard to replace FTP is/was WebDAV. It's not a very modern standard, but it's a standard.
      - drb91 8y ago
        Good point; I never used that directly. Why do you think that hasn’t supplanted FTP?
        dragonwriter 8y ago
        Because SFTP is a better fit for simple (but secure) file transfer, WebDAV handles a lot more, but it's overkill for most of the things FTP was used for. OTOH, AFAICT, SFTP has largely replaced FTP for the system-to-system role (though ad hoc HTTP-based protocols are also common.)
klodolph 8y ago
I don’t think that there’s any reason we should expect HTTP/2 to ever be fully adopted, and it’s not really necessary. I am excited to see TLS adopted everywhere and ALPN, SNI available to everyone who needs it, but once you have ALPN you don’t need to adopt HTTP/2. You can just choose to make HTTP/2 available if you think it will help, and in the future you could choose to make HTTP/3 available as well. As a website operator, the hard part of HTTP/2 was getting TLS certificiates. As an end-user, I'm just happy that popular web pages load faster. And if most of the world still uses HTTP 1.1 I won’t care. Making a datagram-based protocol available will open up a ton of possibilities for cool realtime apps over HTTP. Currently you’re stuck with WebSockets or WebRTC and for some applications these solutions aren’t good enough.
- londons_explore 8y ago
  WebRTC datagrams are very 'close to the wire'. Size them correctly, and they map 1:1 with UDP packets. I can't think of many network applications you couldn't build on top of them.
  - klodolph 8y ago
    The problem with WebRTC is software support. It's not an underlying technical issue with the protocol itself.
  - pthatcherg 8y ago
    You can do the same with QUIC streams (size them appropriately and get a 1:1 mapping with UDP packets).
NuSkooler 8y ago
While HTTP/2 has very clear advantages in many areas, it's losing out on some major HTTP/1 advantages that have allowed it to last so long. Most importantly: Simplicity. One can create HTTP/1 server in just a few lines of code. It's the same sort of reason AT commands are still used over simple serial devices. While a lot of the modern web is great, it also has drawbacks that should be looked at very carefully: A simple HTTP page from yonder can still be rendered just fine. A modern page can't be rendered properly a year or so down the line. We need modern protocols to solve modern problems we've created such as huge pages with tons of links and back and forth traffic to many servers. While I think work needs to be done in both directions, I don't know what we really need to go so far as to push down yet another HTTP/x protocol this soon. HTTP/1 is going to be used for quite a while still, HTTP/2 solves a lot, and where it matters (ie: dealing with specialized servers) QUIC is already and has been in use.
- detaro 8y ago
  > A modern page can't be rendered properly a year or so down the line. Examples?
- Matthias247 8y ago
  The main reason it’s simple is that someone else wrote the most complex code for it: A TCP stack in the OS. Without it, it would be quite painful. With Http2 one can do the same and rely on other people’s implementations to deal with the complexity. There are in the meantime good implementations for nearly every ecosystem. What I would E.g. agree upon is that http2 is a pain for exotic systems or E.g. microcontrollers, due to the window size and buffering requirements that the protocol imposes. But those systems are still free to stay with HTTP/1.1 for as long as they like. Nobody is going to remove support for it anytime soon.
- deathanatos 8y ago
  > One can create HTTP/1 server in just a few lines of code. One can create a non-conforming server in a few lines of code. The actual protocol has a horrendous number of corner cases and weirdness. E.g., determining a message body's size depends on whether content-length is sent, is it chunked, was the request a HEAD request, etc. There's also header folding (whereby a header can be split over multiple lines) though one has the out that the standard allows that to be optional (you can respond w/ 400). Trailers (additional headers after the body) and continuations (allows the client to request a potentially large upload, and the server can reject it prior to the client transmitting the body). Actually parsing headers beyond just a KV mapping, that is, trying to work with any of the actual data in a header is fraught with error: many of them can be specified multiple times, and can thus be in multiple occurrences of the header, or all in a single header but separated by commas, or some mix of the two. (Except cookie headers, those are special.) Some also allow a comma to appear in the value itself, meaning a parser that first splits on comma and then parses the resulting parts is broken. These text protocols, while "simple" in the sense that a human can generally look at the on-the-wire data and parse with their eyeballs, require complex FSMs to parse correctly. (Complex, relative to an equivalent binary protocol with binary-encoded length-prefixed data or even a text protocol that didn't accommodate every random slightly different way of doing it.) Now, HTTP/2 also adds a lot of functionality above and beyond what HTTP/1 has, so that certainly eats up some of the gains in parsing simplicity (and I think it would be fair to say that the outcome is overall more complex). I'd much rather have a binary protocol and good tooling. (And that's much more feasible with today's browser's devtools. I would not want to attempt this with the lame excuse for tooling IE 6 had back in the 90s.) MIME's header encoding of non-ASCII characters is another abomination that I'd toss in this bucket. E.g., Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= (Yes, that's a valid email Subject line.) HTTP supported this at one time, though nowadays the standard has mostly deprecated this: Historically, HTTP has allowed field content with text in the ISO-8859-1 charset [ISO-8859-1], supporting other charsets only through use of [RFC2047] encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset [USASCII]. Newly defined header fields SHOULD limit their field values to US-ASCII octets. A recipient SHOULD treat other octets in field content (obs-text) as opaque data.

gcb0 8y ago

its all mostly driven by Google pushing thu with chrome constant updates. they can update chrome tomorrow to v3, v4, v10... it's all the same. on http2/spdy, they at least had the decency to publish something before forcing everyone into adoption

gregmac 8y ago
It helps that this also pushed the other browser vendors to step up their games. Firefox switched to a Rapid Release cycle. Even Microsoft is now on board with Edge updating fairly regularly (at least compared to IE). A few years ago, web sites and infrastructure had to be built to serve decade-old versions. Now it's reasonable to support only a few years-old versions, and this time frame is continuously shrinking as the current generation of evergreen auto-updating browsers takes more market share. Though I don't like the bit about forcing adoption onto others, I do think that advancing the market to allow standards changes like this to happen in years instead of decades is a good thing.
- h1d 8y ago
  Too bad Windows 10 isn't exactly everyone's favorite and thus IE is still around for some time.
- gcb0 8y ago
  dont drink google coolaid! they all already have ways to release security patches. firefox has a semi-secret/invisible system addon for that. so much that this is still the current way to release security patches and fix internet-breaking bugs. rapid release for new features eas invented by microsoft with IE, to push the agenda on standards bodies. it moved so fast that nonody even remember IE5 or 5.5... and thats the reason google have rapid release. nothing to do with security, as proved on the 1st paragraph.

nextweek2 8y ago

What you are seeing is someone picking up the baton and running with it. HTTP 1.1 has drawbacks which we've been living with for far too long. Getting people used to change was step one, that was HTTP/2, now were in a position to fix pain points. I'd also like to see updates to IMAP, SMTP and FTP to name a few.

numbsafari 8y ago
I'm with you on IMAP and SMTP, as they serve a specific purpose. One thing I don't understand, is why anyone is holding on to FTP at this stage over HTTP. Outside of legacy enterprise "file transfer" appliances, which I deal with all day and can appreciate the inertia around, I just don't understand what the benefit is over HTTP.
- drb91 8y ago
  There’s no standard for HTTP file uploads, with all the permissions that come along with it. Eg you can POST a file to a path, but the behavior is undefined, as is authorization, etc. S3 is probably the closest thing to replacing FTP, and I would hazard a guess that there just isn’t sufficient reason to dump ftp and upgrade infrastructure. Ftp is surprisingly common when integrating between parties, and this can be expensive to change for non technical reasons.
  - treve 8y ago
    The standard to replace FTP is/was WebDAV. It's not a very modern standard, but it's a standard.
    - drb91 8y ago
      Good point; I never used that directly. Why do you think that hasn’t supplanted FTP?
      - dragonwriter 8y ago
        Because SFTP is a better fit for simple (but secure) file transfer, WebDAV handles a lot more, but it's overkill for most of the things FTP was used for. OTOH, AFAICT, SFTP has largely replaced FTP for the system-to-system role (though ad hoc HTTP-based protocols are also common.)

klodolph 8y ago

I don’t think that there’s any reason we should expect HTTP/2 to ever be fully adopted, and it’s not really necessary. I am excited to see TLS adopted everywhere and ALPN, SNI available to everyone who needs it, but once you have ALPN you don’t need to adopt HTTP/2. You can just choose to make HTTP/2 available if you think it will help, and in the future you could choose to make HTTP/3 available as well. As a website operator, the hard part of HTTP/2 was getting TLS certificiates. As an end-user, I'm just happy that popular web pages load faster. And if most of the world still uses HTTP 1.1 I won’t care. Making a datagram-based protocol available will open up a ton of possibilities for cool realtime apps over HTTP. Currently you’re stuck with WebSockets or WebRTC and for some applications these solutions aren’t good enough.

londons_explore 8y ago
WebRTC datagrams are very 'close to the wire'. Size them correctly, and they map 1:1 with UDP packets. I can't think of many network applications you couldn't build on top of them.
- klodolph 8y ago
  The problem with WebRTC is software support. It's not an underlying technical issue with the protocol itself.
- pthatcherg 8y ago
  You can do the same with QUIC streams (size them appropriately and get a 1:1 mapping with UDP packets).

NuSkooler 8y ago

While HTTP/2 has very clear advantages in many areas, it's losing out on some major HTTP/1 advantages that have allowed it to last so long. Most importantly: Simplicity. One can create HTTP/1 server in just a few lines of code. It's the same sort of reason AT commands are still used over simple serial devices. While a lot of the modern web is great, it also has drawbacks that should be looked at very carefully: A simple HTTP page from yonder can still be rendered just fine. A modern page can't be rendered properly a year or so down the line. We need modern protocols to solve modern problems we've created such as huge pages with tons of links and back and forth traffic to many servers. While I think work needs to be done in both directions, I don't know what we really need to go so far as to push down yet another HTTP/x protocol this soon. HTTP/1 is going to be used for quite a while still, HTTP/2 solves a lot, and where it matters (ie: dealing with specialized servers) QUIC is already and has been in use.

detaro 8y ago
> A modern page can't be rendered properly a year or so down the line. Examples?
Matthias247 8y ago
The main reason it’s simple is that someone else wrote the most complex code for it: A TCP stack in the OS. Without it, it would be quite painful. With Http2 one can do the same and rely on other people’s implementations to deal with the complexity. There are in the meantime good implementations for nearly every ecosystem. What I would E.g. agree upon is that http2 is a pain for exotic systems or E.g. microcontrollers, due to the window size and buffering requirements that the protocol imposes. But those systems are still free to stay with HTTP/1.1 for as long as they like. Nobody is going to remove support for it anytime soon.
deathanatos 8y ago
> One can create HTTP/1 server in just a few lines of code. One can create a non-conforming server in a few lines of code. The actual protocol has a horrendous number of corner cases and weirdness. E.g., determining a message body's size depends on whether content-length is sent, is it chunked, was the request a HEAD request, etc. There's also header folding (whereby a header can be split over multiple lines) though one has the out that the standard allows that to be optional (you can respond w/ 400). Trailers (additional headers after the body) and continuations (allows the client to request a potentially large upload, and the server can reject it prior to the client transmitting the body). Actually parsing headers beyond just a KV mapping, that is, trying to work with any of the actual data in a header is fraught with error: many of them can be specified multiple times, and can thus be in multiple occurrences of the header, or all in a single header but separated by commas, or some mix of the two. (Except cookie headers, those are special.) Some also allow a comma to appear in the value itself, meaning a parser that first splits on comma and then parses the resulting parts is broken. These text protocols, while "simple" in the sense that a human can generally look at the on-the-wire data and parse with their eyeballs, require complex FSMs to parse correctly. (Complex, relative to an equivalent binary protocol with binary-encoded length-prefixed data or even a text protocol that didn't accommodate every random slightly different way of doing it.) Now, HTTP/2 also adds a lot of functionality above and beyond what HTTP/1 has, so that certainly eats up some of the gains in parsing simplicity (and I think it would be fair to say that the outcome is overall more complex). I'd much rather have a binary protocol and good tooling. (And that's much more feasible with today's browser's devtools. I would not want to attempt this with the lame excuse for tooling IE 6 had back in the 90s.) MIME's header encoding of non-ASCII characters is another abomination that I'd toss in this bucket. E.g., Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= (Yes, that's a valid email Subject line.) HTTP supported this at one time, though nowadays the standard has mostly deprecated this: Historically, HTTP has allowed field content with text in the ISO-8859-1 charset [ISO-8859-1], supporting other charsets only through use of [RFC2047] encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset [USASCII]. Newly defined header fields SHOULD limit their field values to US-ASCII octets. A recipient SHOULD treat other octets in field content (obs-text) as opaque data.