Re: HTTP/2 vs 1.1 semantics: intermediate codes

On 2014-06-12 10:52, Willy Tarreau wrote:
> On Thu, Jun 12, 2014 at 10:48:10AM +0200, Julian Reschke wrote:
>> On 2014-06-12 10:41, Willy Tarreau wrote:
>>> On Thu, Jun 12, 2014 at 09:53:57AM +0200, Julian Reschke wrote:
>>>>> 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).
>>>
>>> I don't remember it to be honnest, I'll have to take a look.
>>>
>>>> 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.
>>>
>>> I agree with that principle. At the same time I think that if we can do
>>> without it's still better just to avoid carrying some of the
>>> interoperability
>>> issues we had (eg: clients don't wait too long for 100-continue,
>>> intermediaries
>>> have to consume all of them even if multiple responses are sent, etc).
>>
>> But that's a problem specific to 100, right?
>
> Yes clearly.
>
>> I'm totally OK with that one being killed.
>
> Then maybe you're right and we should allow 1xx to pass and redefine
> the semantics there when codes are unknown from the client (ie:
> currently 1xx cannot fall back to the same behaviour as 100 contrary
> to other codes).

Good point. I think we'll need start collecting issues for RFC7230bis.

Best regards, Julian

Received on Thursday, 12 June 2014 09:55:51 UTC