- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 12 Jun 2014 09:53:57 +0200
- To: Willy Tarreau <w@1wt.eu>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2014-06-12 09:44, Willy Tarreau wrote: > Hi Julian, > > On Thu, Jun 12, 2014 at 09:16:44AM +0200, Julian Reschke wrote: >> Hi there, >> >> the current HTTP/2 spec currently points out that there are HTTP/1.1 >> features that are removed, but that there are HTTP/2-specific ways to do >> things better. >> >> I'm mostly ok with that, but think that the reasoning for the 1xx codes >> is really weak. >> >> The main point of 1xx codes (other than expect-100/continue) is that >> servers can return status *and* header field while the request is >> processing. I agree that this isn't used a lot today (maybe not at all), >> but what is the replacement in HTTP/2? >> >> Is there a technical reason why we can't just allow them in HTTP/2? > > Well, the only two 1xx we have now are directly used to fill a miss > in connection management in 1.1. I'd say that 100 is more or less a > poor man's flow control in that it limits sending when not necessary, > and 101 is directly related to the connection itself. Their support > is already messy in many 1.1 implementations. While I'm not seeing > any technical reason for not allowing them, I'm not seeing the need > to have them either, but I suspect that their semantics are never > easy to deal with and could mostly lead to wrong or partial > implementations like we used to have in 1.1. > > Do you have a use case in mind where it could really make a difference > to have them ? I kind of liked the ideas behind 102 (which used the message for progress reporting). My preference would be not to break 1.1 features that aren't broken unless they clearly make HTTP/2 more complex. Is this the case here? At least we shouldn't claim we have a better replacement if we don't. Best regards, Julian
Received on Thursday, 12 June 2014 08:15:55 UTC