https://bz.apache.org/bugzilla/show_bug.cgi?id=63690
--- Comment #10 from Mark Thomas <ma...@apache.org> --- (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?). Right. <snip/> > 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
