Re: #541: CONTINUATION

In message <0E4E566E-11DF-4D52-9163-C836B5F93120@mnot.net>, Mark Nottingham writes:

>2) limiting header sizes to 16K (HPACK'd) in HTTP/2, as per PHK's 
>suggestion

Personally I'd prefer this expression:

	2) All headers, after (any) compression, must fit in a single
	   HEADERS frame.

This expression allows people to negotiate a jumbo-frame extension
and escape the ill-adviced 16383 bytes hard limit.

This is going to be Varnish take on any variant of CONTINUATION
as they are currently specified:  We simply won't touch them,
and sever any connection that tries to use them.

(I think it would be wise to subject HEADERS to flow-control,
but am open for other anti-DoS mechanisms on this point.)

>3) We can't know until we get substantial interop and deployment 
>experience with draft-13.

I don't think we need to floor it on the freeway to see that painting
the windshield was a bad idea, and punting now is just a tacit
acceptance of 0) by inaction.

Poul-Henning

PS:
    Yes, I realize that not having wasted a lot of time implementing
    a protocol I think sucks in too many important ways disqualifies
    me as "a implementor" using Marks strict criteria but the code
    that does not get written due to bad standardization should
    also be listened to.

PPS:
    I'm looking for co-authors for a jumboframe extension draft.

-- 
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 Wednesday, 2 July 2014 12:29:30 UTC