3 ms·

> I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers I've been trying to start a document that describes what I would

> I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers I've been trying to start a document that describes what I would like to see in the next http (apparently http 1.2 was speced already but only added a few headers for something I forgot and that most people don't need). I don't see HTTP2 as solving the problems I see with the web as it is, and want to get people talking about what they see as problems and how to make them better. https://github.com/jimktrains/http_ng https://github.com/jimktrains/http_ng

byuu 12y ago
I'd certainly love to get a group of people together and design a nice HTTP/1.2+ step. But unfortunately it would stand no chance of wide adoption. There's an unbelievable level of bureaucracy and unwillingness to work with outsiders in the major web browser developer teams. Nonetheless, it's nice to at least put proposals out there. Would you be interested in my 'Content-Push: "filename", ETag' header for your spec? Basically, a server could tell you in advance all of the stuff you're going to need to load the page, and give you the ETags (which would usually be sanely formatted timestamps or file hashes), which could prevent lots of If-None-Match connection requests. That would greatly help on thread-based servers like Apache. And FWIW, I really like the WWW-Authenication: Mutual idea.
- jimktrains2 12y ago
  I don't actually expect it to get traction, but I hate when I say I don't like HTTP2 and then having to rehash everything all over, every time. At least now I can point to a document that I can update, get input on, collaborate on, and show people who can analyze a more well-structured argument than belongs in a ton forum posts. I think the best case scenario would cumulate with a FF add-on and apache module that would implement a bunch of the ideas in it as a proof-of-concept that could be pointed to as well. Regarding the content-push header, It would be interesting to have a 4-phase (req, meta-res, meta-req, res) connection instead of a 2-phase (req, res). So, in the meta-response, the server would add a bunch of content-push headers. In the meta-req, which is all happening over the same connection, the client lists all the resources it needs. In the final response, the server would respond in a MIME-like fashion with all the resources requested. I actually kind-of like that: bulk resource downloading but without the need to send all of them every time. It doesn't clash too much with the current model (i.e. if no content-push header is there, the response is treated as it would be under http/1.1. It's still able to be debugged easily and isn't trying to implement transport control either. It also removes much of the complexity and overhead of HTTP keep-alive. Would you want to write out your idea and submit a pull request, or would you mind if I wrote up a portion about it?

byuu 12y ago

I'd certainly love to get a group of people together and design a nice HTTP/1.2+ step. But unfortunately it would stand no chance of wide adoption. There's an unbelievable level of bureaucracy and unwillingness to work with outsiders in the major web browser developer teams. Nonetheless, it's nice to at least put proposals out there. Would you be interested in my 'Content-Push: "filename", ETag' header for your spec? Basically, a server could tell you in advance all of the stuff you're going to need to load the page, and give you the ETags (which would usually be sanely formatted timestamps or file hashes), which could prevent lots of If-None-Match connection requests. That would greatly help on thread-based servers like Apache. And FWIW, I really like the WWW-Authenication: Mutual idea.

jimktrains2 12y ago
I don't actually expect it to get traction, but I hate when I say I don't like HTTP2 and then having to rehash everything all over, every time. At least now I can point to a document that I can update, get input on, collaborate on, and show people who can analyze a more well-structured argument than belongs in a ton forum posts. I think the best case scenario would cumulate with a FF add-on and apache module that would implement a bunch of the ideas in it as a proof-of-concept that could be pointed to as well. Regarding the content-push header, It would be interesting to have a 4-phase (req, meta-res, meta-req, res) connection instead of a 2-phase (req, res). So, in the meta-response, the server would add a bunch of content-push headers. In the meta-req, which is all happening over the same connection, the client lists all the resources it needs. In the final response, the server would respond in a MIME-like fashion with all the resources requested. I actually kind-of like that: bulk resource downloading but without the need to send all of them every time. It doesn't clash too much with the current model (i.e. if no content-push header is there, the response is treated as it would be under http/1.1. It's still able to be debugged easily and isn't trying to implement transport control either. It also removes much of the complexity and overhead of HTTP keep-alive. Would you want to write out your idea and submit a pull request, or would you mind if I wrote up a portion about it?