arkanovicz commented on issue #277: URL: https://github.com/apache/tomcat/pull/277#issuecomment-616771727
@markt-asf This happens for instance in SSE components (tomcat does *not* provide such components), or more generally in *any* J2EE filters or servlets, coded before HTTP/2.0, which want to ensure that the connection is kept alive. @rmaucher It means that you choose tomcat to let buggy server-side components break HTTP/2.0 streams. Other user agents do *always* ignore this faulty header, so what's the point in sending it in the first place? Helping to find bad client code by breaking more often? Of course, it's a strategy, but considering the vast amount of HTTP/1.1-specific code in the nature that is supposed to migrate to HTTP/2.0, it's better to just log an informative warning and get things straight. Or directly throw. @michael-o I'm using a recent curl. There is a misunderstanding, here, I'm talking about a header sent by the server in the HTTP response. > Since it's now 2020, shouldn't it be doable to block any attempt to set the connection header by the application ? > That would also allow some clean up in the current code that sets the header and has to take account of any value that may have been set by the application. @rmaucher That would mean to throw the exception right away, it's enough to remove the try catch in this patch. Yes, certainly simpler. > If applied (and I'm not convinced it should be) the formatting of the PR needs fixing to be consistent with the Tomcat code. @markt-asf Can you give me some pointers on the needed fixes? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
