Re: Fragmentation for headers: why jumbo != continuation.

In message <>
, Roberto Peon writes:
>Content-Type: text/plain; charset=UTF-8
>In the case of a server, it must interpret. If it can do so in a streaming
>fashion, it can do so in a streaming fashion. If not, it must buffer until
>it has the entire header set. That is true of fragmented and non-fragmented

I belive we have consensus to put all the :xxx headers first.

This means that the moment a receiver sees the first non-colon
header it can trust the :xxx headers.

But no other header can be trusted until the full header-set has
been received, since they can be revised (or in the case of
Content-Length: invalidate the entire request)

In other words your "streaming fashion" is hard limited to the URL.

I have a hard time seeing why anybody would ever send CONTINUATION
frames if all the server cares about is the URL ?

I have an even harder time seeing that we should bend over backwards
and inconvenience all the high-traffic implementations for their
ability to do so.

In other words:  It (still) doesn't make any sense Roberto.

>For a proxy, it is a sender and a receiver.
>Allowing fragmentation allows the sender-half of the proxy to reduce its
>memory commitment.
>Again, nothing changed on the receiver side, which implies that the proxy's
>memory commitment is reduced.

Try as I might, have never found a compliant HTTP proxy which would forward
a request without receiving the full header-set first.

Do you know of any ?  If so, please share.

I know of hackish loadbalancers which operate at IP packet level, and
which expects that the information they require for load-balancing fit
inside a single ethernet frame, but given that no HTTP standard ever
talked about ethernet frames, I think we can agree that they are not
anywhere near being compliant.

So please tell us more about these mythological "header-streaming"
proxies you keep talking about, nobody else seems to have ever seen
or heard about them.

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 Saturday, 12 July 2014 08:00:23 UTC