[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #8 from Boris Petrov --- 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? As I said above, we're using "jQuery File Upload" (https://github.com/blueimp/jQuery-File-Upload) which splits the file in 1 MB chunks. Then, I guess, they do the POST request. Isn't then splitting that request with its body a Chrome/Firefox responsibility? If by "client" you mean Chrome/Firefox... is it possible that both of them are so inefficient/not-clever? If you mean a JavaScript library - then I probably am missing something. Some insight would be appreciated. Thanks! -- 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
[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690 --- Comment #7 from Mark Thomas --- Take a look at the following lines in the log: Connection [1], Stream [7], Frame type [DATA], Flags [0], Payload size [...] It looks like there is some buffering going on. The first 6 data frames are 5x2852 bytes and 1x2124 bytes for a total of exactly 16k. The first 24 packets are 20x2852, 3x2124 and 1x2123 for a total of 64k-1. The 25th packet is 1 byte giving a total of 64k. A similar (but not completely identical pattern) follows for the rest of the upload. It looks like the library you are using has various internal buffers and what you are seeing (in terms of data packet size) is the result of interactions between those buffers (I'm assuming there is no HTTP/2 proxy between the client and Tomcat else things will get more complicated). Small HTTP/2 packets are inefficient. Lots of them are considered to be abusive and in some servers (not Tomcat) result in a DoS. Tomcat has expanded its overhead protection to protect against such abusive traffic. The default settings considers any non-final DATA frame of less than 1024 bytes abusive. The smaller the DATA frame, the more abusive it is considered. I'd recommend opening an issue against the library you are using as it could be argued it should be sending fewer, larger HTTP/2 frames. It could also be argued that Tomcat should use a lower overheadDataThreadhold. However, the counter argument is that a lower threshold is only required for inefficient clients. Where inefficient becomes abusive is an interesting question and the answer will vary from server to server. As I said, in Tomcat's case it is never abusive, only inefficient, but we want to encourage clients to be efficient. I'm leaning towards leaving the default as is for now but is is definitely something we should keep an eye on as more users pick up the latest 9.0.x and 8.5.x releases. If we see a lot of issues like this then we may need to review the default. I'll leave this open for now but I am leaning towards resolving it as some form of "not a Tomcat issue". -- 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
[GitHub] [tomcat] michael-o commented on issue #195: BZ 63684: Wrapper never passed to RealmBase#hasRole() for given secur…
michael-o commented on issue #195: BZ 63684: Wrapper never passed to RealmBase#hasRole() for given secur… URL: https://github.com/apache/tomcat/pull/195#issuecomment-524982814 @markt-asf, any opinion? I'd like to merge by tomorrow. 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63625] Unable to start Tomcat 7.0.96 (stop by 0xc0000005)
https://bz.apache.org/bugzilla/show_bug.cgi?id=63625 laurence.labo...@xmedius.com changed: What|Removed |Added CC||laurence.labo...@xmedius.co ||m -- 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
[Bug 63695] session_cookie attribute does not work?
https://bz.apache.org/bugzilla/show_bug.cgi?id=63695 --- Comment #2 from kimc@gmail.com --- (In reply to Christopher Schultz from comment #1) > Did you change the JSESSIONID cookie name in Tomcat, or just in mod_jk? > Those two configurations must agree with each other. Of course, I did, that's why I had the logs below [Tue Aug 13 16:40:07.270 2019] [6532:18068] [debug] init_ws_service::jk_isapi_plugin.c (3267): Forwarding request header Cookie : TESTSESSIONID=ASfXUomeuKIAUYQKlGfFPk81z4ZCFVW32wVdAmmJqDBLaV7iy7SU8hXlXs3OLSg0.engine1 * my context.xml My point is that once session_cookie is changed from its default, It never look for session id from request headers. -- 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
[Bug 63695] session_cookie attribute does not work?
https://bz.apache.org/bugzilla/show_bug.cgi?id=63695 Christopher Schultz changed: What|Removed |Added OS||All --- Comment #1 from Christopher Schultz --- Did you change the JSESSIONID cookie name in Tomcat, or just in mod_jk? Those two configurations must agree with each other. -- 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
[GitHub] [tomcat] peteruhnak opened a new pull request #196: fix JSSE_OPTS quoting
peteruhnak opened a new pull request #196: fix JSSE_OPTS quoting URL: https://github.com/apache/tomcat/pull/196 Otherwise if JSSE_OPTS is set with the same value, the quotation will cancel itself in the if condition. ``` if not ""-Djdk.tls.ephemeralDHKeySize=2048"" ``` resulting in the following error ``` =2048"" was unexpected at this time. ``` 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 With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63696] uriworkermap does not work properly if it has /* pattern
https://bz.apache.org/bugzilla/show_bug.cgi?id=63696 Rainer Jung changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED OS||All --- Comment #1 from Rainer Jung --- As far as I remember, the isapi redirector support some kind of virtual hosting in IIS by first prefixing the URL with the local server name before mapping the request using uriworkermap.properties. Only if it can't map that URI, it will next try the raw URI without prefixed vhost. So the log tells us, that it first tries to map /localhost:48080/tomcat/test.jsp and that URI matches the root map, not the tomcat map. I guess port 48080 is something you configured. If that is stable, you could try the follwoing rules instead in uriworkermap.properties: /localhost:48080/tomcat*=tomcat /localhost:48080/*=root Any non-root context mapping would not require the vhost prefix in the rules, because it would never match a /HOST:PORT/ prefixed URI. Only /* unfortunately matches it. Alternatively you can stay with your config but add another first rule (exclusion rule starting with an exclamation mark): !/localhost:48080/tomcat*=root You can read a bit about the IIS vhost feature and maps under: http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html#Virtual_host_integration Regards, Rainer -- 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
