Re: CONNECT and HTTP/2.0

The final problem is that we need to specify what code to use in
RST_STREAM when the TCP connection breaks (TCP RST isn't the only
reason that might happen, we have to allow for timeouts).

I've proposed the definition of a CONNECT_ERROR code (10) for this purpose.

See https://github.com/http2/http2-spec/commit/ac528cdbb64a1b2e62dac4e79358752b12863d19

On 3 October 2013 14:27, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 24 September 2013 11:02, William Chan (陈智昌) <willchan@chromium.org> wrote:
>> Sorry for the delay. https://github.com/http2/http2-spec/pull/249.
>
> That's OK, I was on vacation (that is, closer to 100% of the time than yours).
>
> I've accepted the pull request, but I think that there are a few
> things to resolve.
>
> 1. The :host header.  I'm not comfortable with the MAY on this.  Given
> that this is 100% new functionality, I think that we need better
> justification than the fact that some HTTP/1.x (or even 0.9) clients
> set different values for the target URI and Host header.  Just because
> they did something wrong, it doesn't mean that we have to.  Requiring
> the omission of :host doesn't lose anything, ... unless existing
> proxies are doing something special based on its value.
>
> 2. I need to find some way to incorporate the comments that Ilari made
> here: http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/1036.html
>  (Not including the suggestion to fix the scheme to "tcp", even though
> it's a very interesting idea.  But that opens up a whole new can of
> extensibility worms that I'd rather leave closed.)  We also need to
> say that implementations are obligated to send END_STREAM as soon as
> possible if they see END_STREAM, otherwise we violate assumptions in
> TCP.  Those more familiar with TCP can correct me here if I've
> misinterpreted RFC 793 or am ignorant of actual behaviour.

Received on Thursday, 3 October 2013 22:33:53 UTC