Re: HTTP/2 vs 1.1 semantics: intermediate codes

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 ?

Regards,
Willy

Received on Thursday, 12 June 2014 07:44:45 UTC