Bug 17656 - scheme and secure Connector server.xml configuration attributes ignored by CoyoteConnector HTTP/1.1
Summary: scheme and secure Connector server.xml configuration attributes ignored by Co...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Connector:Coyote HTTP/1.1 (show other bugs)
Version: 4.1.18
Hardware: PC Linux
: P3 critical with 3 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 18706 20919 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-03-05 06:27 UTC by Randy Watler
Modified: 2004-11-16 19:05 UTC (History)
2 users (show)



Attachments
proposed patch, (tested on 4.1.18 ported forward) (3.89 KB, patch)
2003-03-06 00:17 UTC, Randy Watler
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Randy Watler 2003-03-05 06:27:55 UTC
Overview Description:

    Use of the common scheme and secure attributes in Connector server.xml
    configuration for CoyoteConnector HTTP/1.1 is ignored in the released
    4.1.18 build. This used to work as expected in 4.1.10, (see below).

    Our hosting architecture employs external SSL acceleration hardware in
    front of standalone Tomcat servers and needs to pass scheme and secure
    information to our webapps. To do this, we specify the following in
    the server.xml file:

    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8543" minProcessors="8" maxProcessors="128"
               enableLookups="false" acceptCount="64" debug="0"
               connectionTimeout="300000" scheme="https" secure="true"
               useURIValidationHack="false" disableUploadTimeout="true"/>

    The specification of "https" and "true" no longer is effective in
    setting the standard Servlet 2.3 ServletRequest.getScheme() and
    ServletRequest.isSecure() return values. Instead, "http" and false are
    always returned, respectively.

    Because the static Connector configuration information is no longer
    propagated to our web application servlets, our application fails to
    run properly.

Steps to Reproduce:

    1. configure Tomcat 4.1.18 to use standalone CoyoteConnector.
    2. specify Connector scheme attribute as something other than "http"
       and/or set secure attribute to "false".
    3. access the standard request getScheme() and/or isSecure() methods in
       a servlet registered to the Connector.

Actual Results:

    ServletRequest.getScheme() will return "http" and
    ServletRequest.isSecure() will return false when accessed from the
    servlet.

Expected Results:

    ServletRequest.getScheme() and ServletRequest.isSecure() should reflect
    what is specified in the Connector configuration.

Additional Information:

    It appears that this problem was introduced in 4.1.13 while making the
    following change to
    coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java and other
    files:

    -----------------------
    revision 1.10
    date: 2002/09/29 17:07:44;  author: nacho;  state: Exp;  lines: +9 -14
    Bug#12998 HTTPS gets changed to HTTP://servername:443
    Reported by marcus.kellermann at bentley.com

    The processor (HTTP11 or ajp13) should set the scheme and port prior
    to this point, in an ajp13 connection doesnt make sense to get the
    secure flag from the connector secure flag.
    -----------------------

    In prior versions of this file, settings for the request scheme was
    always copied from the Connector/CoyoteConnector configuration. With
    this change, the Processor is now responsible for setting the request
    information correctly. In our case, the Http11Processor cannot know
    about the external hardware and fails to upgrade the logical connection
    to https/secure.
Comment 1 Randy Watler 2003-03-06 00:17:50 UTC
Created attachment 5173 [details]
proposed patch, (tested on 4.1.18 ported forward)
Comment 2 william.barker 2003-03-23 09:07:33 UTC
Patch applied.  Thanks Much.
Comment 3 william.barker 2003-04-04 18:35:08 UTC
*** Bug 18706 has been marked as a duplicate of this bug. ***
Comment 4 william.barker 2003-06-19 20:09:28 UTC
*** Bug 20919 has been marked as a duplicate of this bug. ***
Comment 5 Ralf Albrecht 2003-07-22 09:44:32 UTC
Maybe I misunderstood the comments, but it seems that the bug is still
contained in version 4.1.24.