- From: <K.Morgan@iaea.org>
- Date: Wed, 16 Jul 2014 09:04:06 +0000
- To: <ietf-http-wg@w3.org>
- Message-ID: <0356EBBE092D394F9291DA01E8D28EC201187F430A@SEM002PD.sg.iaea.org>
After reading through Section 3.2 'Starting HTTP/2 for "http" URIs' again, I have the following question, observation and suggestion regarding requests with an "Upgrade: h2c" header. *Question: Is it possible to pipeline?* It seems to me that it is impossible to pipeline requests with an 'Upgrade' header without possibly causing problems. If the server switches to h2c, pipelined HTTP/1.x requests will be parsed as h2c frames and obviously cause errors. On the other hand, if the server doesn't switch to h2c and the client tried to pipeline h2c requests, that will also cause errors. *Observation: Two responses?* When the server accepts the "Upgrade" and switches to h2c, it seems a bit bizarre that two responses are sent in response to the original HTTP/1.x request with the "Upgrade" header. 1) the "101 switching protocols" HTTP/1.x response, and 2) the h2c response on stream 1 for the URL in the original request. What happens with "101" responses for other upgrade protocols e.g. WebSockets? Does the original request have any semantic meaning once the switch is made? Currently we have a "HTTP2-Settings" header for sending the required HTTP2-Settings frame that initiates the connection. Would it be possible to add or replace "HTTP2-Settings" with a "HTTP2-Frames" header that includes a base-64 encoded value of the following frames: SETTINGS HEADERS+. Where HEADERS+ includes the first request hpack-encoded plus any *speculative requests* the client wants to pipeline in anticipation of the server switching to h2c? This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
Received on Wednesday, 16 July 2014 09:04:50 UTC