--- Comment #10 from Mark Thomas <> ---
(In reply to Boris Petrov from comment #8)
> Hi, thanks for the detailed answer.
> There is no intermediate HTTP/2 proxy.
> Before I open an issue somewhere, could you please explain me something. I'm
> not sure I fully understand what's going on but how can a JavaScript library
> manage the HTTP/2 frames at all?

It will depend on the API it uses to pass data to the browser. For example, if
the API offers the capability to a) control the write buffer size and b) flush
writes then the client can - broadly - control the size of the DATA frames
written. I'm not at all familiar with the API in use. What I would suggest is
to test a simple POST with the same file and no Javascript library and see how
that behaves.

(In reply to Christopher Schultz from comment #9)
> 1024 might be too high for a default, but the good news is that the
> "abusive" threshold can be changed (right?).



> That's a scant 44 bytes.
> Not every application will be sending large documents around.

Which is why the threshold doesn't apply to DATA frames with the EOS (end of
stream) flag set. Sending a small request body in a single DATA frame is fine
even if the body is just a single byte. Sending lots of small (less than 1024
bytes by default) DATA frames when you could send one larger DATA frame is not.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to