Re: Request line parsing

+1 Thorough and clear write up On Mon, Mar 23, 2020 at 06:01 Mark Thomas wrote: > Hi, > > I am currently looking at the request line parsing. I'll try and set out > each issue in turn. > > End of line parsing > === > > Prior to the recent changes, Tomcat allowed CRLF or LF to

[Bug 63691] Add a no-op JarScanner

https://bz.apache.org/bugzilla/show_bug.cgi?id=63691 --- Comment #11 from Gustavo Stachera --- (In reply to Joshua Lipstone from comment #8) > Can you please either undo this or change it so that the Jars are only > scanned if they match the inclusion filter. > As of 9.0.30, if you wanted to set

Re: Request line parsing

On 23/03/2020 17:33, Christopher Schultz wrote: > On 3/23/20 11:35, Mark Thomas wrote: > Sounds good. I entirely missed your actual proposal, which was below > your signature and after your references: Sorry about that. I was editing and re-organising and got distracted. Mark

Re: Request line parsing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/23/20 11:35, Mark Thomas wrote: > On 23/03/2020 14:59, Christopher Schultz wrote: > > > >> My only concern here is that request line + header-processing >> really has to match whatever reverse proxy servers are doing as >> well, and

Re: Remaining Tomcat 10 items

On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas wrote: > On 23/03/2020 09:37, Rémy Maucherat wrote: > > Hi, > > > > I'm looking at the TODO list, in addition to some extra items. In order > ... > > > > - Java 11. > > I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be] > > required

[Bug 64259] New: Cannot precompile jsps with jetty-jspc-maven-plugin since 8.5.51

https://bz.apache.org/bugzilla/show_bug.cgi?id=64259 Bug ID: 64259 Summary: Cannot precompile jsps with jetty-jspc-maven-plugin since 8.5.51 Product: Tomcat 8 Version: 8.5.53 Hardware: PC OS: Linux

Re: Request line parsing

On 23/03/2020 13:28, Rémy Maucherat wrote: > On Mon, Mar 23, 2020 at 2:01 PM Mark Thomas > wrote: > With all of the above in mind I propose: > > - Doing nothing! I think Tomcat is striking the right balance here. > > This means: > GET /CRLF   ->

Re: Request line parsing

On 23/03/2020 14:59, Christopher Schultz wrote: > My only concern here is that request line + header-processing really > has to match whatever reverse proxy servers are doing as well, and > that's really not something we can know for sure. I don't think there > is a single safe implementation

Re: Remaining Tomcat 10 items

Am 2020-03-23 um 10:37 schrieb Rémy Maucherat: Hi, I'm looking at the TODO list, in addition to some extra items. In order ... You missed one point: Remove deprecated code marked for removal in Tomcat 10. M - To

Re: Remaining Tomcat 10 items

Am 2020-03-23 um 15:42 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 3/23/20 05:37, Rémy Maucherat wrote: I'm looking at the TODO list, in addition to some extra items. In order ... - Remove APR connector. Is there still general approval for that, and

Re: Request line parsing

Am 2020-03-23 um 14:01 schrieb Mark Thomas: Hi, I am currently looking at the request line parsing. I'll try and set out each issue in turn. End of line parsing === Prior to the recent changes, Tomcat allowed CRLF or LF to mark the end of a line. The unwanted side effect was

Re: Request line parsing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/23/20 09:01, Mark Thomas wrote: > Hi, > > I am currently looking at the request line parsing. I'll try and > set out each issue in turn. > > End of line parsing === > > Prior to the recent changes, Tomcat allowed CRLF or

[tomcat] branch master updated: Remove internal Range helpers

This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new b9aff64 Remove internal Range helpers b9aff64 is

[Bug 64210] parsing request headers fail

https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #13 from Xing --- (In reply to Mark Thomas from comment #12) > The correct line terminator for an HTTP/1.0 request is CRLF ("/r/n"). You > should use that. Thanks a lot, I'm compiling :) Xing -- You are receiving this mail

Re: Remaining Tomcat 10 items

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 3/23/20 05:37, Rémy Maucherat wrote: > I'm looking at the TODO list, in addition to some extra items. In > order ... > > - Remove APR connector. Is there still general approval for that, > and is that still the plan for Tomcat 10.0 ? See

[Bug 64210] parsing request headers fail

https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #12 from Mark Thomas --- The correct line terminator for an HTTP/1.0 request is CRLF ("/r/n"). You should use that. -- You are receiving this mail because: You are the assignee for the bug.

Re: Request line parsing

On Mon, Mar 23, 2020 at 2:01 PM Mark Thomas wrote: > Hi, > > I am currently looking at the request line parsing. I'll try and set out > each issue in turn. > > End of line parsing > === > > Prior to the recent changes, Tomcat allowed CRLF or LF to mark the end > of a line. The

[tomcat] branch 9.0.x updated: Check that scan set is empty as it is more accurate

This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch 9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/9.0.x by this push: new 304c72a Check that scan set is empty as it is more

[tomcat] branch 8.5.x updated: Check that scan set is empty as it is more accurate

This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/8.5.x by this push: new 6582703 Check that scan set is empty as it is more

Request line parsing

Hi, I am currently looking at the request line parsing. I'll try and set out each issue in turn. End of line parsing === Prior to the recent changes, Tomcat allowed CRLF or LF to mark the end of a line. The unwanted side effect was that CR could appear in the header value. This

[Bug 64210] parsing request headers fail

https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #11 from Xing --- (In reply to Mark Thomas from comment #10) > (In reply to Xing from comment #9) > > I don't think the current solution resolved all the header issues. > > For example, our project use Socket TCP to monitor Tomcat

[tomcat] branch master updated: Check that scan set is empty as it is more accurate

This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new be649bc Check that scan set is empty as it is

[GitHub] [tomcat] rmaucher commented on issue #264: fix regression: only skip jar-scanning completely if scanSet is empty

rmaucher commented on issue #264: fix regression: only skip jar-scanning completely if scanSet is empty URL: https://github.com/apache/tomcat/pull/264#issuecomment-602567135 I hadn't seen this PR at all as there was a BZ there already and it didn't mention it. I will make the extra

[GitHub] [tomcat] Iridias commented on issue #264: fix regression: only skip jar-scanning completely if scanSet is empty

Iridias commented on issue #264: fix regression: only skip jar-scanning completely if scanSet is empty URL: https://github.com/apache/tomcat/pull/264#issuecomment-602564747 > Fixed with 9c6563b Hm, that would ignore the case, that `jarsToScan` is specified but empty. (Because then

[GitHub] [tomcat] martin-g closed pull request #264: fix regression: only skip jar-scanning completely if scanSet is empty

martin-g closed pull request #264: fix regression: only skip jar-scanning completely if scanSet is empty URL: https://github.com/apache/tomcat/pull/264 This is an automated message from the Apache Git Service. To respond to

[GitHub] [tomcat] martin-g commented on issue #264: fix regression: only skip jar-scanning completely if scanSet is empty

martin-g commented on issue #264: fix regression: only skip jar-scanning completely if scanSet is empty URL: https://github.com/apache/tomcat/pull/264#issuecomment-602555158 Fixed with https://github.com/apache/tomcat/commit/9c6563bf6ac723cda4e78d0e8c1a996fa1b8ce56

[Bug 64210] parsing request headers fail

https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #10 from Mark Thomas --- (In reply to Xing from comment #9) > I don't think the current solution resolved all the header issues. > For example, our project use Socket TCP to monitor Tomcat status like this: > "get /platform

[Bug 64210] parsing request headers fail

https://bz.apache.org/bugzilla/show_bug.cgi?id=64210 --- Comment #9 from Xing --- I don't think the current solution resolved all the header issues. For example, our project use Socket TCP to monitor Tomcat status like this: "get /platform HTTP/1.0\n\n" (double \n, no \r) Before version 8.5.50

Re: Remaining Tomcat 10 items

On 23/03/2020 09:37, Rémy Maucherat wrote: > Hi, > > I'm looking at the TODO list, in addition to some extra items. In order ... > > - Java 11. > I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be] > required for Tomcat 10 ? It could be better to do it in 10.1. No. It will be

Remaining Tomcat 10 items

Hi, I'm looking at the TODO list, in addition to some extra items. In order ... - Java 11. I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be] required for Tomcat 10 ? It could be better to do it in 10.1. - Remove the use of system properties to control configuration wherever