5 ms·

Why do I feel like one of the most meaningful things I can do with my professional life would be to find some like-minded engineers and design HTTP 1.2?

toast0 7y ago
The one thing that HTTP/2 gives me that I find useful is a clear indication when the server closed an idle connection, so that clients can tell if their request was likely seen or not when the connection is closed.
asdfasgasdgasdg 7y ago
It is probably not the most meaningful thing you can do unless you are positioned to get vendors to adopt your proposal. A proposal without adoption is just paper. I suspect that the largest relevant vendor will be very reluctant to take up any proposal in this direction, which will constrain the amount of impact your idea can have. This isn't a comment on the quality your idea of what HTTP/1.2 should be, just a comment on the likelihood of your ideas being congruent with what's important to Chromium's primary sponsor.
colechristensen 7y ago
Many things would benefit from being redone "right" but the hurdles to get over are almost insurmountable. I'd like to rebuild unix front the ground up.
- Ericson2314 7y ago
  OS is easier than network because less coordination is needed. Stay tuned, Unix will be replaced.
- layoutIfNeeded 7y ago
  > I'd like to rebuild unix front the ground up. Pls implement proper async syscalls this time. Thx.
  - colechristensen 7y ago
    what do you mean by "proper"?
    - deathanatos 7y ago
      Many — most? — of the system calls in nixes, even Linux, that deal w/ I/O are blocking calls. Sure, you can chuck them into a background thread, but even that isn't quite what you want, since you can't interrupt the background thread while the blocking call is blocking. Sure, we've got async networking, timers, events nowadays. But disk I/O is almost completely async unaware (and even if you can work around the main problem of I/O to a file, there's a ton of auxiliary calls like link, unlink, rename, mkdir, chmod/chown, etc. that are blocking and, AFAIK, have no async equivalents). I'm not sure if you can wait on a process (I think kqueue might support this, but IDK about Linux). And more fundamentally, I don't think you want synchronous I/O calls that only allow you to do one thing per thread at a time. You want to schedule as much I/O as you have available with the OS as it becomes available, s.t. the OS has a more complete picture of what I/O is actually outstanding, to better schedule it.
      - FullyFunctional 7y ago
        Take that one step further and do what NFSv4 does: do more per command (system call); instead of sending a single command (with a single response coming back), send a sequence of command and the responses from all of them (terminating early if any of them fails).
      - pjc50 7y ago
        I got halfway through a back-of-the-envelope spec for how this might work. Change "everything is a file" to "everything is shared pages", but impose the additional sanity restriction that each accessor of a shared page should choose to mostly write or mostly read using lockfree structures. Then instead of the operating system allocating a "standard in" for you, every process would be handed two event ring buffers, one for incoming and one for outgoing events. On waking, all the process has to do is scan the ring buffer. Potentially easy to make suitable for microkernels too, by passing the buffers directly from process to disk subsystem.
- IshKebab 7y ago
  That's Plan9 isn't it?
toomim 7y ago
Probably because HTTP is important! What would you change in 1.2?
- m_eiman 7y ago
  I would replace cookies with a browser controlled session id, 128 random bits encoded as hex.
  - yeaaaaah 7y ago
    Something like HTTP state tokens? https://mikewest.github.io/http-state-tokens/draft-west-http-state-tokens.html https://mikewest.github.io/http-state-tokens/draft-west-http...
    - m_eiman 7y ago
      Yes, something like that! Except also remove support for old-style cookies, which from a quick scan that spec doesn't do.
- gambler 7y ago
  Ideally, everything related to sessions and domains. The security model we operate under on the web is completely outdated, which adds a ton of complexity to everything else. Secondly, I would look into cutting out all the parts of the HTTP protocol normal websites aren't commonly using to reduce the complexity of the implementations. A lot of things HTTP does are probably better off being move to other protocols altogether.

toast0 7y ago

The one thing that HTTP/2 gives me that I find useful is a clear indication when the server closed an idle connection, so that clients can tell if their request was likely seen or not when the connection is closed.

asdfasgasdgasdg 7y ago

It is probably not the most meaningful thing you can do unless you are positioned to get vendors to adopt your proposal. A proposal without adoption is just paper. I suspect that the largest relevant vendor will be very reluctant to take up any proposal in this direction, which will constrain the amount of impact your idea can have. This isn't a comment on the quality your idea of what HTTP/1.2 should be, just a comment on the likelihood of your ideas being congruent with what's important to Chromium's primary sponsor.

colechristensen 7y ago

Many things would benefit from being redone "right" but the hurdles to get over are almost insurmountable. I'd like to rebuild unix front the ground up.

Ericson2314 7y ago
OS is easier than network because less coordination is needed. Stay tuned, Unix will be replaced.
layoutIfNeeded 7y ago
> I'd like to rebuild unix front the ground up. Pls implement proper async syscalls this time. Thx.
- colechristensen 7y ago
  what do you mean by "proper"?
  - deathanatos 7y ago
    Many — most? — of the system calls in nixes, even Linux, that deal w/ I/O are blocking calls. Sure, you can chuck them into a background thread, but even that isn't quite what you want, since you can't interrupt the background thread while the blocking call is blocking. Sure, we've got async networking, timers, events nowadays. But disk I/O is almost completely async unaware (and even if you can work around the main problem of I/O to a file, there's a ton of auxiliary calls like link, unlink, rename, mkdir, chmod/chown, etc. that are blocking and, AFAIK, have no async equivalents). I'm not sure if you can wait on a process (I think kqueue might support this, but IDK about Linux). And more fundamentally, I don't think you want synchronous I/O calls that only allow you to do one thing per thread at a time. You want to schedule as much I/O as you have available with the OS as it becomes available, s.t. the OS has a more complete picture of what I/O is actually outstanding, to better schedule it.
    - FullyFunctional 7y ago
      Take that one step further and do what NFSv4 does: do more per command (system call); instead of sending a single command (with a single response coming back), send a sequence of command and the responses from all of them (terminating early if any of them fails).
    - pjc50 7y ago
      I got halfway through a back-of-the-envelope spec for how this might work. Change "everything is a file" to "everything is shared pages", but impose the additional sanity restriction that each accessor of a shared page should choose to mostly write or mostly read using lockfree structures. Then instead of the operating system allocating a "standard in" for you, every process would be handed two event ring buffers, one for incoming and one for outgoing events. On waking, all the process has to do is scan the ring buffer. Potentially easy to make suitable for microkernels too, by passing the buffers directly from process to disk subsystem.
IshKebab 7y ago
That's Plan9 isn't it?

toomim 7y ago

Probably because HTTP is important! What would you change in 1.2?

m_eiman 7y ago
I would replace cookies with a browser controlled session id, 128 random bits encoded as hex.
- yeaaaaah 7y ago
  Something like HTTP state tokens? https://mikewest.github.io/http-state-tokens/draft-west-http-state-tokens.html https://mikewest.github.io/http-state-tokens/draft-west-http...
  - m_eiman 7y ago
    Yes, something like that! Except also remove support for old-style cookies, which from a quick scan that spec doesn't do.
gambler 7y ago
Ideally, everything related to sessions and domains. The security model we operate under on the web is completely outdated, which adds a ton of complexity to everything else. Secondly, I would look into cutting out all the parts of the HTTP protocol normal websites aren't commonly using to reduce the complexity of the implementations. A lot of things HTTP does are probably better off being move to other protocols altogether.