[GitHub] [tomcat] markt-asf commented on a change in pull request #417: Fix BZ 65272. Restore the use of LF as an HTTP line terminator
markt-asf commented on a change in pull request #417: URL: https://github.com/apache/tomcat/pull/417#discussion_r622815587 ## File path: webapps/docs/changelog.xml ## @@ -143,6 +143,12 @@ request line, ensure that all the available data is included in the error message. (markt) + +65272: Restore the optional HTTP feature that allows +LF to be treated as a line terminator as well as the Review comment: Can do. -- 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
[GitHub] [tomcat] markt-asf commented on a change in pull request #417: Fix BZ 65272. Restore the use of LF as an HTTP line terminator
markt-asf commented on a change in pull request #417:
URL: https://github.com/apache/tomcat/pull/417#discussion_r622818008
##
File path: java/org/apache/coyote/http11/Http11InputBuffer.java
##
@@ -550,10 +550,15 @@ boolean parseRequestLine(boolean keptAlive, int
connectionTimeout, int keepAlive
prevChr = chr;
chr = byteBuffer.get();
if (chr == Constants.CR) {
-// Possible end of request line. Need LF next.
+// Possible end of request line. Need LF next else invalid.
} else if (prevChr == Constants.CR && chr == Constants.LF) {
+// CRLF is the standard line terminator
end = pos - 1;
parsingRequestLineEol = true;
+} else if (chr == Constants.LF) {
Review comment:
It would make the code a little more complex and there is nothing in the
spec to suggest that self-consistency is required. If we were going to make the
behaviour configurable I can see how this would fit into an option that allow
varying degrees of LF use. Eg: none, consistent, any.
My current thinking is to essentially hard-code the any option unless
someone identifies a good reaaon not to.
--
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
[GitHub] [tomcat] markt-asf commented on a change in pull request #417: Fix BZ 65272. Restore the use of LF as an HTTP line terminator
markt-asf commented on a change in pull request #417:
URL: https://github.com/apache/tomcat/pull/417#discussion_r622818008
##
File path: java/org/apache/coyote/http11/Http11InputBuffer.java
##
@@ -550,10 +550,15 @@ boolean parseRequestLine(boolean keptAlive, int
connectionTimeout, int keepAlive
prevChr = chr;
chr = byteBuffer.get();
if (chr == Constants.CR) {
-// Possible end of request line. Need LF next.
+// Possible end of request line. Need LF next else invalid.
} else if (prevChr == Constants.CR && chr == Constants.LF) {
+// CRLF is the standard line terminator
end = pos - 1;
parsingRequestLineEol = true;
+} else if (chr == Constants.LF) {
Review comment:
It would make the code a little more complex and there is nothing in the
spec to suggest that self-consistency is required. If we were going to make the
behaviour configurable I can see how this would fit into an option that allow
varying degrees of LF use. Eg: none, consistent, any.
My current thinking is to essentially hard-code the any option unless
someone identifies a good reason not to.
--
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
[GitHub] [tomcat] markt-asf commented on a change in pull request #417: Fix BZ 65272. Restore the use of LF as an HTTP line terminator
markt-asf commented on a change in pull request #417:
URL: https://github.com/apache/tomcat/pull/417#discussion_r622821247
##
File path: java/org/apache/coyote/http11/Http11InputBuffer.java
##
@@ -841,7 +846,8 @@ private HeaderParseStatus parseHeader() throws IOException {
if (chr == Constants.CR && prevChr != Constants.CR) {
Review comment:
It shouldn't. What it should do is detect if a line starts with CRLF or
LF and if it does set the HeaderParseStatus.DONE state. Anything else is passed
through to be parsed as the start of the header name. That particular line is
handling the case where the lines starts with CR which may be the start of a
CRLF sequence.
--
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
[Bug 65273] NoClassDefFoundError in Apache POI dependency after upgrading to Tomcat 8.5.57 in Jira
https://bz.apache.org/bugzilla/show_bug.cgi?id=65273 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Mark Thomas --- I can confirm that this isn't a Tomcat issue so I will be closing this as invalid. To reproduce the issue I used the following: - Ubuntu 20.04 fully patched - Installed Jira latest (8.16.1) - Installed R4J - Created a simple project (TEST) - Created a single issue - Activated the TEST project in R4J - Selected TEST from the Requirements menu - Clicked Export -> Word You only see the ClassCastException the first time you click export. To see it again you need to restart Jira. I have done some digging via remote debugging and I can confirm that this is a class loading issue. When R4J calls POI the XMLEventFactory class is loaded by an instance of BundleWiringImpl$BundleClassLoader. The parent of that class loader is Tomcat's web application class loader. When POI calls XMLEventFactory.newInstance() that triggers the standard search using the Thread's context class loader (TCCL). Interestingly, the TCCL at this point is not the class loader that loaded XMLEventFactory above. The result is an instance of org.apache.xerces.stax.XMLEventFactoryImpl which is loaded by Tomcat's web application class loader. Its super class is XMLEventFactory BUT that class is loaded by the system class loader. Hence when the assignment is attempted, you get the ClassCastException because you have two versions of XMLEventFactory loaded by different class loaders. I don't know Jira's class loader structure well enough to provide a specific solution but I can say what a possible general solution might look like. Option 1. Don't ship stax-api with R4J. Let it use the version provided by the JRE. Option 2. Provide a stax implementation with R4J *and* ensure that the search mechanism finds it. (Maybe set TCCL to XMLEventFactory.class.getClassLoader() before the call. Remember to use a finally block to restore the old value afterwards.) Option 3. Newer versions of POI don't use STAX - at least not at the point where the error is occurring. Updating to a newer version of POI may avoid the 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
[Bug 65277] New: org.apache.coyote.ajp.AjpProcessor.service Error processing request java.lang.NullPointerException
https://bz.apache.org/bugzilla/show_bug.cgi?id=65277
Bug ID: 65277
Summary: org.apache.coyote.ajp.AjpProcessor.service Error
processing request java.lang.NullPointerException
Product: Tomcat 9
Version: 9.0.7
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: saranchan0...@gmail.com
Target Milestone: -
SEVERE [ajp-nio-8109-exec-244] org.apache.coyote.ajp.AjpProcessor.service Error
processing request
java.lang.NullPointerException
at
org.apache.catalina.connector.Request.notifyAttributeAssigned(Request.java:1544)
at
org.apache.catalina.connector.Request.setAttribute(Request.java:1530)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:147)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:651)
at
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:291)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:394)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:764)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1379)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
29-Apr-2021 11:31:59.560 SEVERE [ajp-nio-8109-exec-969]
org.apache.catalina.core.StandardHostValve.invoke Exception Processing null
java.lang.NullPointerException
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:236)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:608)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:651)
at
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:291)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:394)
at
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:764)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1379)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)
WARNING [main] org.apache.catalina.startup.SetAllPropertiesRule.begin
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 'server' to '
' did not find a matching property.
29-Apr-2021 11:31:59.607 SEVERE [ajp-nio-8109-exec-977]
org.apache.catalina.core.StandardHostValve.invoke Exception Processing null
java.lang.NullPointerException
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:236)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:608)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:651)
at
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:291)
at
org.apache.catalina.core.StandardEngine
