Re: CONNECT and HTTP/2.0

WINDOW_UPDATE isn't "on a" stream, it is "about a" stream, or however we're
calling that today.

That text could use some clarifying, though.
-=R


On Fri, Oct 4, 2013 at 11:37 PM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

> The current text says:
>
> """
> Frame types other than DATA<http://http2.github.io/http2-spec/index.html#DATA>
>  or RST_STREAM <http://http2.github.io/http2-spec/index.html#RST_STREAM> MUST
> NOT be sent on a connected stream, and MUST be treated as a stream error (
> Section 5.4.2<http://http2.github.io/http2-spec/index.html#StreamErrorHandler>)
> if received.
> """
>
> I believe that WINDOW_UPDATE must be allowed to the connected stream since
> it is  subject to stream-level flow control unless it is disabled.
> I also think PRIORITY frame should not be prohibited. The client has a
> freedom to adjust stream priority of connected stream just as other streams.
>
> Best regards,
>
> Tatsuhiro Tsujikawa
>
>
>
> On Fri, Oct 4, 2013 at 7:33 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> 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.
>>
>>
>