https://issues.apache.org/bugzilla/show_bug.cgi?id=54010
Priority: P2
Bug ID: 54010
Assignee: dev@tomcat.apache.org
Summary: Suggestion for code improvement (avoiding potential
bug)
Severity: normal
Classification: Unclassified
OS: Linux
Reporter: shensiu...@gmail.com
Hardware: PC
Status: NEW
Version: 5.5.36
Component: Connector:Coyote
Product: Tomcat 5
In connectors/jk/java/org/apache/jk/common/HandlerRequest.java
coyote.Request's schemeMB is assigned in 2 places.
1st place:
400 boolean isSSL = msg.getByte() != 0;
401 if( isSSL ) {
402 // XXX req.setSecure( true );
403 req.scheme().setString("https");
404 }
2nd place:
518 case AjpConstants.SC_A_SSL_CERT :
519 req.scheme().setString( "https" );
and similar assignments for SC_A_SSL_CIPHER and SC_A_SSL_SESSION cases below.
It seems they do not make sense because the packet's 8-bit field is designated
for telling whether it's SSL or not. So the 1st place is enough. Adding the 2nd
place may pose potential bug in that a packet with the 8-bit SSL field being 0
and suffixes of SC_A_SSL_* key-value pairs can later incorrect trigger a wrong
redirection message pointing to a https location.
A simple correction is to honor the 8-bit SSL-field in packet and delete the 3
lines of 2nd place assigning "https".
Even though the chances of such spurious packet is low, but it's best we can
have threat-free, semantic-correct tomcat code.
The same lines of code remain in 6.0 and 7.0.
But maybe I misunderstand the code, in which case please kindly point out.
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
