Re: Stuck in a train -- reading HTTP/2 draft.

In message <CAH_y2NHRz6khc61+c-7jDQJK56PayO_3Q4ExVOM_Yjmhr_n3Lw@mail.gmail.com>
, Greg Wilkins writes:

>> Page 28ff: Padding
>> > ------------------
>> > For this reason I would make padding part of the framing format,
>> > rather than the individual message types.
>>
>
>I would prefer padding be removed totally.

I'm certainly not convinced that padding as proposed is compliant
with Gettys 1st and 3rd laws:

	1.Do not add new functionality unless an implementor cannot
	  complete a real application without it.

	3.The only thing worse than generalizing from one example is
	  generalizing from no examples at all.


I can see that padding can be very valuable in some specific security
contexts, although I find the required infrastructure support to
be a rather formidable challenge.

Ie:  How do we get W3C to support "Create this form, when you submit
replies the password field must go into a dedicated HTTP/2.0 frame
padded to a length of NN bytes" ?

It's not like anything prevents the application layer from padding
the submitted XML with whitespace, if an entry form contains a field
called "password".

>Failing that then on every frame is better than on specific frame types.

Yes, absolutely:  The more orthogonal the protocol, the faster
implementations will be possible.

>> It's also pretty non-obvious why we need CONTINUATION in the
>> > first place:  Why not simply send HEADERS until one of them has
>> > the END_HEADERS bit set ?
>
>It is indeed non obvious.  But I have tried many times to come up with a
>way of removing them and I have concluded that they are a necessary
>consequence of other design decisions - specifically the single shared
>state table of header encoding.

But what difference does it make that you send:

	HEADERS
	CONTINUATION
	CONTINUATION + END_HEADERS

vs.

	HEADERS
	HEADERS
	HEADERS + END_HEADERS

I don't see any value added from having two different frame types ?

>> > For obvious DoS reasons, it's a mistake to not apply flowcontrol
>> > to HEADERS.
>
>Indeed.  However I do not think that strict DoS is the main concern
>here.    Instead I believe there will eventually be collusions between
>applications, clients and servers to use the lack of flow control to
>attempt to gain benefits vs other traffic on shared connections.

That's sort of comparing grand bank robbery to petty candy theft...

>However, it is nigh impossible to flow control headers when we have decided
>to have a single state table for [...]

I really don't see why you can't just count the frames containing
the headers towards the windows, compressed or not compressed ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 17 June 2014 21:05:58 UTC