4 ms·

On the one hand, any HTTP 2.0 spec that still has cookies is a travesty. On the other hand, I think we need to get some input from dissenters other than PHK (n

by debacle 12y ago

On the one hand, any HTTP 2.0 spec that still has cookies is a travesty. On the other hand, I think we need to get some input from dissenters other than PHK (not that I don't agree with him).

__david__ 12y ago
Honest question: if you don't have cookies, then where do you keep your state?
- debacle 12y ago
  In the session, where it belongs.
  - gazrogers 12y ago
    How do you link the browser to the session, if not with cookies?
    - youngtaff 12y ago
      You create a session identifiers as part of the protocol but that then breaks the semantics being compatible with HTTP/1.x I think it will come and I think PHK's ideas a really interesting just that it's a step too far right now.
    - deleted 12y ago
      [deleted]
gsnedders 12y ago
This is by design. The aim for HTTP/2 was always a new messaging scheme for HTTP/1.1 semantics. Basically, any HTTP/1.1 message can be converted to an HTTP/2 message (and this can be done by intermediaries); the only headers not expected to be supported in HTTP/2 are those that fall into the category of connection control (e.g., Connection). From the charter: > It is expected that HTTP/2.0 will: > * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. > * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). Quite probably a more radical, new version of HTTP, that drops message compatibility would be a good idea — but that's a lot harder to design and harder to deploy. As the old adage goes, "we believe in rough consensus and running code" — we have running code for a new message serialisation, and rough consensus for it. We should accept just that as done.
- debacle 12y ago
  So if HTTP 2.0 is a superset of HTTP 1.1 then why the hell can't they just leave it as SPDY? Which goes back to PHK's argument about the IETF getting caught with their pants down.

by debacle 12y ago

On the one hand, any HTTP 2.0 spec that still has cookies is a travesty. On the other hand, I think we need to get some input from dissenters other than PHK (not that I don't agree with him).

__david__ 12y ago

Honest question: if you don't have cookies, then where do you keep your state?

debacle 12y ago
In the session, where it belongs.
- gazrogers 12y ago
  How do you link the browser to the session, if not with cookies?
  - youngtaff 12y ago
    You create a session identifiers as part of the protocol but that then breaks the semantics being compatible with HTTP/1.x I think it will come and I think PHK's ideas a really interesting just that it's a step too far right now.
  - deleted 12y ago
    [deleted]

gsnedders 12y ago

This is by design. The aim for HTTP/2 was always a new messaging scheme for HTTP/1.1 semantics. Basically, any HTTP/1.1 message can be converted to an HTTP/2 message (and this can be done by intermediaries); the only headers not expected to be supported in HTTP/2 are those that fall into the category of connection control (e.g., Connection). From the charter: > It is expected that HTTP/2.0 will: > * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields. > * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2). Quite probably a more radical, new version of HTTP, that drops message compatibility would be a good idea — but that's a lot harder to design and harder to deploy. As the old adage goes, "we believe in rough consensus and running code" — we have running code for a new message serialisation, and rough consensus for it. We should accept just that as done.

debacle 12y ago
So if HTTP 2.0 is a superset of HTTP 1.1 then why the hell can't they just leave it as SPDY? Which goes back to PHK's argument about the IETF getting caught with their pants down.