Re: Expect: + Upgrade: = ...

On 7/09/2013 5:35 a.m., Martin Thomson wrote:
> On 6 September 2013 04:23, Amos Jeffries <squid3@treenet.co.nz> wrote:
>> There is nothing preventing the server emitting further 100 status frames
>> inHTTP/2 format.
> 100, or 1xx?

1xx. In this specific case we are talking about 100 (or HTTP/2 version 
of that).

> I thought that the text was good.  It specifically doesn't say
> anything about what happens in the upgraded protocol, because that's
> the business of that protocol.  For HTTP/2.0, I guess that in theory
> you might get more 1xx status codes, but you won't get 100, because
> we're prohibiting that.

Why is 100 being prohibited is what I am questioning? I thought it was 
Expect that was being deprecated for transmission in HTTP/2. 
100-continue has other uses far beyond Expect and there seems to be no 
reason not to respond in HTTP/2 format to a HTTP/1 feature sent using 
HTTP/1. The text in Upgrade would seem to require it.

If the server has chosen to switch protocols it need to ensure that the 
new protocol is capable of responding to the earlier request 
appropriately. I

And the arguments I've already put forwared for allowing a 100 frame to 
be sent in HTTP/2 format to ensure the HTTP/1.1 payload gets delivered 
show that the

Going back to the earlier proposal:
"

Well maybe start with something along these lines ?

    http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-23#section-6.2.1

    If a server wants to receive a request payload body before deciding to
    switch the protocol, it may have to send a 100-continue interim response
    first, according to the rules in 6.2.1.

    A client waiting for a 101 status code to upgrade the protocol must still
    be prepared to handle other 1xx interim responses first before receiving
    the 101 status code confirming the protocol upgrade.

"

It does not address the original thread starting question: What happens if the new protool is used to send the 100 after the 101. Assuming that the new protocol is capable of that to begin with.
  Does the client see the 101 as a final state and start sending the payload immediately?
  Does it wait for a 100 which the new protocol may be used to deliver slightly later?
  Does it wait for its timeout?

It has become clear in this thread we all disagree on the implementation of that part which will cause interoperation issues. So the text does need to be clearer on that case.
- Retaining the timeout is a no-brainer, but does impose the HTTP/1 blocking problem onto whatever protocol was upgraded to.
- Retaining the payload in HTTP/1 format is agreed (I think).


Also, keep in mind that this will not just be affecting Expect:, but any other similar HTTP/1 feature which relies on a specific 1xx status to trigger some behaviour.

I propose a third paragraph after the above proposals text, stating that a client which uses such features along with Upgrade needs to be able to handle the response required by those features to happen within the new protocol, or not use them at all.

That still leves the problem of what a intermediary gateway should do. It may seem simple for the gateway to send 100 then 101, but when the applicatino places (ncorrect) assumptions that eth 100 comes from the origin server things get tricky.

>
>> So like I said 100 and 101 can occur in any order. There is no reason for
>> the order of them to have any effect on the transaction as a whole. 101
>> has no effect on the *request* bytes and 100 has no effect on the
>> *response* bytes. Why are people seeing any problem here at all?
> I don't think that a server upgrading to HTTP/2.0 should be sending
> 100 responses that control the sending of the HTTP/1.1 request.  I
> just can't imagine how that would be healthy.

How woud it be unhealthy if both protocols support sending the 1xx 
status frame required?

Or rather is it bad enough that we should mandate a gateway to emit 
100-continue on behalf of orign servers N hops away with unknown 
application-layer semantics depending on the Expect being end-to-end?

Amos

Received on Saturday, 7 September 2013 03:37:34 UTC