DO NOT REPLY [Bug 34113] New: - [PATCH] setHeader( ) method in Response object does not clear multiple values

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34113>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34113

           Summary: [PATCH] setHeader( ) method in Response object does not
                    clear multiple values
           Product: Tomcat 5
           Version: Nightly Build
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Connector:Coyote
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: mtdean@thirdcontact.com


The setHeader( ) method in the org.apache.coyote.Response class does not clear
existing values for a header with multiple values.

According to the Servlet Specification version 2.4 (SRV.5.2, para 2):
-----
The setHeader method sets a header with a given name and value. A previous
header is replaced by the new header. Where a set of header values exist for the
name, the values are cleared and replaced with the new value.
-----

This requirement has been true since at least Servlets 2.2 (same location in
Serlvets 2.3 specification; SRV.6.2, para 2 in the Servlets 2.2 specification).

Where only one value exists, the setHeader( ) method properly replaces it with
the specified value.

Attached is a patch that fixes the bug.  In creating the patch, I found that:

  a) the setHeader( ) method in Response relies on the
org.apache.tomcat.util.http.MimeHeaders class's setValue( ) method.
  b) the setValue( ) method in MimeHeaders relies on getValue( ) in MimeHeaders
  c) the getValue( ) method in MimeHeaders explicitly states, "If more than one
such field is in the header, an arbitrary one is returned."
  d) the MimeHeaders class's source code is prefixed with: "XXX XXX XXX Need a
major rewrite  !!!!"

Therefore, with the existing MimeHeaders class, all existing header values must
be removed before calling getValue( ).  If the MimeHeaders class is rewritten,
this requirement may be alleviated by a design change in consideration of the
Servlet Specification's requirements for setHeader( ).

The attached patch simply removes the named header (by calling MimeHeader's
removeHeader( ) method) before calling MimeHeader's setValue( ) method.  This
means that the removeHeader( ) method will be called with every execution of the
Response's setHeader( ) method.  Since removeHeader( ) iterates over every
header, we incur a penalty for every execution of setHeader( ), and the penalty
grows as the number of headers increases.  However, since:

  a) there is no way to find out whether multiple values exist for a specified
header (other than iterating as is done by removeHeader( ))
  b) the containsHeader( ) and getHeader( ) methods iterate over the headers (by
calling getValue( )) (as is done by removeHeader( ))
  c) the average number of headers is small (assumed to be about 8)

attempting to determine if multiple values exist for the header before calling
removeHeader( ) is fruitless since the same penalty is paid whether zero, one,
or multiple values exist for the named header and the penalty is identical to
that imposed by calling the removeHeader( ) method without first checking for
the existence of a header.  If checking first, the penalty would double for the
case where multiple values exist.  If the assumption that the number of headers
is small holds true, the penalty should be minimal.

I'm marking the severity as minor because the bug is unlikely to affect many
users (only those trying to replace all values of a header with multiple values)
and workarounds exist (i.e. ensure that the headers are set to their correct
value the first time ;), or reset the response while retaining and setting the
values that should not be replaced).  However, until this bug is fixed, Tomcat
is not in compliance with the Servlet Specification.  ;)

This bug is also confirmed to exist in Tomcat  CVS, 5.5.8, 5.5.7, and in 5.0.30
code.  It may also exist in Tomcat 4.x and Tomcat 3.x.

Attached patch fixes the bug.  The patch is against Tomcat 5.5.8 source and
applies cleanly to CVS.

Attached WAR file contains an example of the problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org